Request and combined response broadcasting to processors coupled to other processors within node and coupled to respective processors in another node

ABSTRACT

A data processing system includes a first processing node and a second processing node. The first processing node includes a plurality of first processing units coupled to each other for communication, and the second processing node includes a plurality of second processing units coupled to each other for communication. Each of the plurality of first processing units is coupled to a respective one of the plurality of second processing units in the second processing node by a respective one of a plurality of point-to-point links.

CROSS-REFERENCE TO RELATED APPLICATION(S)

The present application is a continuation of U.S. patent applicationSer. No. 11/236,458, filed on Sep. 27, 2005, now U.S. Pat. No.7,380,102, and entitled “Data Processing System, Method and InterconnectFabric Supporting High Bandwidth Communication Between Nodes” which isalso related to the following U.S. patent applications, which areassigned to the assignee hereof and incorporated herein by reference intheir entireties:

U.S. patent application Ser. No. 11/055,305; and

U.S. patent application Ser. No. 11/054,820.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to data processing systems and,in particular, to an improved interconnect fabric for data processingsystems.

2. Description of the Related Art

A conventional symmetric multiprocessor (SMP) computer system, such as aserver computer system, includes multiple processing units all coupledto a system interconnect, which typically comprises one or more address,data and control buses. Coupled to the system interconnect is a systemmemory, which represents the lowest level of volatile memory in themultiprocessor computer system and which generally is accessible forread and write access by all processing units. In order to reduce accesslatency to instructions and data residing in the system memory, eachprocessing unit is typically further supported by a respectivemulti-level cache hierarchy, the lower level(s) of which may be sharedby one or more processor cores.

SUMMARY OF THE INVENTION

As the clock frequencies at which processing units are capable ofoperating have risen and system scales have increased, the latency ofcommunication between processing units via the system interconnect hasbecome a critical performance concern. To address this performanceconcern, various interconnect designs have been proposed and/orimplemented that are intended to improve performance and scalabilityover conventional bused interconnects.

The present invention provides an improved data processing system,interconnect fabric and method of communication in a data processingsystem. In one embodiment, a data processing system includes a firstprocessing node and a second processing node. The first processing nodeincludes a plurality of first processing units coupled to each other forcommunication, and the second processing node includes a plurality ofsecond processing units coupled to each other for communication. Each ofthe plurality of first processing units is coupled to a respective oneof the plurality of second processing units in the second processingnode by a respective one of a plurality of point-to-point links.

All objects, features, and advantages of the present invention willbecome apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. However, the invention, as well as apreferred mode of use, will best be understood by reference to thefollowing detailed description of an illustrative embodiment when readin conjunction with the accompanying drawings, wherein:

FIG. 1 is a high level block diagram of a processing unit in accordancewith the present invention;

FIG. 2A is a high level block diagram of a first exemplary embodiment ofa data processing system in accordance with the present invention;

FIG. 2B is a high level block diagram of a second exemplary embodimentof a data processing system in which multiple nodes are coupled to forma supernode in accordance with the present invention;

FIG. 3 is a time-space diagram of an exemplary operation including arequest phase, a partial response phase and a combined response phase;

FIG. 4A is a time-space diagram of an exemplary operation of system-widescope within the data processing system of FIG. 2A;

FIG. 4B is a time-space diagram of an exemplary operation of node-onlyscope within the data processing system of FIG. 2A;

FIG. 4C is a time-space diagram of an exemplary supernode broadcastoperation within the data processing system of FIG. 2B;

FIGS. 5A-5C depict the information flow of the exemplary supernodebroadcast operation depicted in FIG. 4C;

FIGS. 5D-5E depict an exemplary data flow for an exemplary supernodebroadcast operation in accordance with the present invention;

FIG. 6 is a time-space diagram of an exemplary operation, illustratingthe timing constraints of an arbitrary data processing system topology;

FIGS. 7A-7B illustrate an exemplary link information allocation for thefirst and second tier links in accordance with the present invention;

FIG. 7C is an exemplary embodiment of a partial response field for awrite request that is included within the link information allocation;

FIG. 8 is a block diagram illustrating a portion of the interconnectlogic of FIG. 1 utilized in the request phase of an operation;

FIG. 9 is a more detailed block diagram of the local hub address launchbuffer of FIG. 8;

FIG. 10 is a more detailed block diagram of the tag FIFO queues of FIG.8;

FIGS. 11 and 12 are more detailed block diagrams of the local hubpartial response FIFO queue and remote hub partial response FIFO queueof FIG. 8, respectively;

FIGS. 13A-13D are flowcharts respectively depicting the request phase ofan operation at a local master, local hub, remote hub, and remote leaf;

FIG. 13E is a high level logical flowchart of an exemplary method ofgenerating a partial response at a snooper in accordance with thepresent invention;

FIG. 14 is a block diagram illustrating a portion of the interconnectlogic of FIG. 1 utilized in the partial response phase of an operation;

FIGS. 15A-15C are flowcharts respectively depicting the partial responsephase of an operation at a remote leaf, remote hub, local hub, and localmaster;

FIG. 16 is a block diagram illustrating a portion of the interconnectlogic of FIG. 1 utilized in the combined response phase of an operation;

FIGS. 17A-17C are flowcharts respectively depicting the combinedresponse phase of an operation at a local hub, remote hub, and remoteleaf; and

FIG. 18 is a more detailed block diagram of an exemplary snoopingcomponent of the data processing system of FIG. 2A or FIG. 2B.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENT I. Processing Unit andData Processing System

With reference now to the figures and, in particular, with reference toFIG. 1, there is illustrated a high level block diagram of an exemplaryembodiment of a processing unit 100 in accordance with the presentinvention. In the depicted embodiment, processing unit 100 is a singleintegrated circuit including two processor cores 102 a, 102 b forindependently processing instructions and data. Each processor core 102includes at least an instruction sequencing unit (ISU) 104 for fetchingand ordering instructions for execution and one or more execution units106 for executing instructions. The instructions executed by executionunits 106 may include, for example, fixed and floating point arithmeticinstructions, logical instructions, and instructions that request readand write access to a memory block.

The operation of each processor core 102 a, 102 b is supported by amulti-level volatile memory hierarchy having at its lowest level one ormore shared system memories 132 (only one of which is shown in FIG. 1)and, at its upper levels, one or more levels of cache memory. Asdepicted, processing unit 100 includes an integrated memory controller(IMC) 124 that controls read and write access to a system memory 132 inresponse to requests received from processor cores 102 a, 102 b andoperations snooped on an interconnect fabric (described below) bysnoopers 126.

In the illustrative embodiment, the cache memory hierarchy of processingunit 100 includes a store-through level one (L1) cache 108 within eachprocessor core 102 a, 102 b and a level two (L2) cache 110 shared by allprocessor cores 102 a, 102 b of the processing unit 100. L2 cache 110includes an L2 array and directory 114, masters 112 and snoopers 116.Masters 112 initiate transactions on the interconnect fabric and accessL2 array and directory 114 in response to memory access (and other)requests received from the associated processor cores 102 a, 102 b.Snoopers 116 detect operations on the interconnect fabric, provideappropriate responses, and perform any accesses to L2 array anddirectory 114 required by the operations. Although the illustrated cachehierarchy includes only two levels of cache, those skilled in the artwill appreciate that alternative embodiments may include additionallevels (L3, L4, etc.) of on-chip or off-chip in-line or lookaside cache,which may be fully inclusive, partially inclusive, or non-inclusive ofthe contents the upper levels of cache.

As further shown in FIG. 1, processing unit 100 includes integratedinterconnect logic 120 by which processing unit 100 may be coupled tothe interconnect fabric as part of a larger data processing system. Inthe depicted embodiment, interconnect logic 120 supports an arbitrarynumber t1 of “first tier” interconnect links, which in this case includein-bound and out-bound X, Y and Z links. Interconnect logic 120 furthersupports an arbitrary number t2 of second tier links, designated in FIG.1 as in-bound and out-bound A and B links. With these first and secondtier links, each processing unit 100 may be coupled for bi-directionalcommunication to up to t1/2+t2/2 (in this case, five) other processingunits 100. Interconnect logic 120 includes request logic 121 a, partialresponse logic 121 b, combined response logic 121 c and data logic 121 dfor processing and forwarding information during different phases ofoperations. In addition, interconnect logic 120 includes a configurationregister 123 including a plurality of mode bits utilized to configureprocessing unit 100. As further described below, these mode bitspreferably include: (1) a first set of one or more mode bits thatselects a desired link information allocation for the first and secondtier links; (2) a second set of one or more mode bits that specify whichof the first and second tier links of the processing unit 100 areconnected to other processing units 100; (3) a third set of one or moremode bits that determines a programmable duration of a protection windowextension; (4) a fourth set of one or more mode bits that predictivelyselects a scope of broadcast for operations initiated by the processingunit 100 on an operation-by-operation basis from among a node-onlybroadcast scope or a system-wide scope, as described in above-referencedU.S. patent application Ser. No. 11/055,305; and (5) a fifth set of oneor more mode bits indicating whether the processing unit 100 belongs toa processing node coupled to at least one other processing node in a“supernode” mode in which broadcast operations span multiple physicalprocessing nodes coupled in the manner described below with reference toFIG. 2B.

Each processing unit 100 further includes an instance of response logic122, which implements a portion of a distributed coherency signalingmechanism that maintains cache coherency between the cache hierarchy ofprocessing unit 100 and those of other processing units 100. Finally,each processing unit 100 includes an integrated I/O (input/output)controller 128 supporting the attachment of one or more I/O devices,such as I/O device 130. I/O controller 128 may issue operations andreceive data on the X, Y, Z, A and B links in response to requests byI/O device 130.

Referring now to FIG. 2A, there is depicted a block diagram of a firstexemplary embodiment of a data processing system 200 formed of multipleprocessing units 100 in accordance with the present invention. As shown,data processing system 200 includes eight processing nodes 202 a 0-202 d0 and 202 a 1-202 d 1, which in the depicted embodiment, are eachrealized as a multi-chip module (MCM) comprising a package containingfour processing units 100. The processing units 100 within eachprocessing node 202 are coupled for point-to-point communication by theprocessing units' X, Y, and Z links, as shown. Each processing unit 100may be further coupled to processing units 100 in two differentprocessing nodes 202 for point-to-point communication by the processingunits' A and B links. Although illustrated in FIG. 2A with adouble-headed arrow, it should be understood that each pair of X, Y, Z,A and B links are preferably (but not necessarily) implemented as twouni-directional links, rather than as a bi-directional link.

General expressions for forming the topology shown in FIG. 2A can begiven as follows:

-   -   Node[I][K].chip[J].link[K] connects to        Node[J][K].chip[I].link[K], for all I≠J; and    -   Node[I][K].chip[I].link[K] connects to Node[I][not        K].chip[I].link[not K]; and    -   Node[I][K].chip[I].link[not K] connects either to:        -   (1) Nothing in reserved for future expansion; or        -   (2) Node[extra][not K].chip[I].link[K], in case in which all            links are fully utilized (i.e., nine 8-way nodes forming a            72-way system); and        -   where I and J belong to the set {a, b, c, d} and K belongs            to the set {A,B}.

Of course, alternative expressions can be defined to form otherfunctionally equivalent topologies. Moreover, it should be appreciatedthat the depicted topology is representative but not exhaustive of dataprocessing system topologies embodying the present invention and thatother topologies are possible. In such alternative topologies, forexample, the number of first tier and second tier links coupled to eachprocessing unit 100 can be an arbitrary number, and the number ofprocessing nodes 202 within each tier (i.e., I) need not equal thenumber of processing units 100 per processing node 100 (i.e., J).

Even though fully connected in the manner shown in FIG. 2A, allprocessing nodes 202 need not communicate each operation to all otherprocessing nodes 202. In particular, as noted above, processing units100 may broadcast operations with a scope limited to their processingnode 202 or with a larger scope, such as a system-wide scope includingall processing nodes 202.

As shown in FIG. 18, an exemplary snooping device 1900 within dataprocessing system 200, for example, an snoopers 116 of L2 (or lowerlevel) cache or snoopers 126 of an IMC 124, may include one or more baseaddress registers (BARs) 1902 identifying one or more regions of thereal address space containing real addresses for which the snoopingdevice 1900 is responsible. Snooping device 1900 may optionally furtherinclude hash logic 1904 that performs a hash function on real addressesfalling within the region(s) of real address space identified by BAR1902 to further qualify whether or not the snooping device 1900 isresponsible for the addresses. Finally, snooping device 1900 includes anumber of snoopers 1906 a-1906 m that access resource 1910 (e.g., L2cache array and directory 114 or system memory 132) in response tosnooped requests specifying request addresses qualified by BAR 1902 andhash logic 1904.

As shown, resource 1910 may have a banked structure including multiplebanks 1912 a-1912 n each associated with a respective set of realaddresses. As is known to those skilled in the art, such banked designsare often employed to support a higher arrival rate of requests forresource 1910 by effectively subdividing resource 1910 into multipleindependently accessible resources. In this manner, even if theoperating frequency of snooping device 1900 and/or resource 1910 aresuch that snooping device 1900 cannot service requests to accessresource 1910 as fast as the maximum arrival rate of such requests,snooping device 1900 can service such requests without retry as long asthe number of requests received for any bank 1912 within a given timeinterval does not exceed the number of requests that can be serviced bythat bank 1912 within that time interval.

Those skilled in the art will appreciate that SMP data processing system100 can include many additional unillustrated components, such asinterconnect bridges, non-volatile storage, ports for connection tonetworks or attached devices, etc. Because such additional componentsare not necessary for an understanding of the present invention, theyare not illustrated in FIG. 2A or discussed further herein.

FIG. 2B depicts a block diagram of an exemplary second embodiment of adata processing system 200 in which multiple processing units 100 arecoupled to form a “supernode” in accordance with the present invention.As shown, data processing system 220 includes two processing nodes 202 a0 and 202 b 0, which in the depicted embodiment, are each realized as amulti-chip module (MCM) comprising a package containing four processingunits 100 in accordance with FIG. 1. The processing units 100 withineach processing node 202 are coupled for point-to-point communication bythe processing units' X, Y, and Z links, as shown. Each processing unit100 is further coupled to a respective processing unit 100 in the otherprocessing node 202 for point-to-point communication by the processingunits' A and/or B links. Although illustrated in FIG. 2B with adouble-headed arrow, it should be understood that each pair of X, Y, Z,A and B links are preferably (but not necessarily) implemented as twouni-directional links, rather than as a bi-directional link.

General expressions for forming the topology shown in FIG. 2B can begiven as follows:

Node[I].chip[J].link[L] connects to Node[not I].chip[not J].link[L]; and

Node[I].chip[K].link[L] connects to Node[not I].chip[not K].link[L],

where I belongs to the set {a, b}, J belongs to the set {a, b}, Kbelongs to the set {c,d}, and L belongs to the set {A,B}.

It should further be appreciated that the depicted topology isrepresentative but not exhaustive of data processing system topologiesembodying the present invention and that other topologies havingmultiple links coupling particular pairs of nodes are possible. Asdescribed above with reference to FIG. 2A, in such alternativetopologies, the number of first tier and second tier links coupled toeach processing unit 100 can be an arbitrary number. In addition,additional processing nodes 202 may be coupled to processing nodes 202 a0 and 202 b 0 by additional second tier links.

Topologies such as that depicted in FIG. 2B can be employed when it isdesirable to maximize the bandwidth of inter-node communication. Forexample, if affinity between particular processes and their associateddata is not sufficiently great for operations to be predominantlyserviced within a single processing node 202, the topology of FIG. 2Bmay be employed to improve inter-node communication bandwidth (e.g., inthis case by up to a factor of 4). Improving inter-node bandwidth byincreasing the number of second tier links coupling particular pairs ofnodes can thus yield significant performance benefits for particularworkloads.

II. Exemplary Operation

Referring now to FIG. 3, there is depicted a time-space diagram of anexemplary operation on the interconnect fabric of data processing system200 of FIG. 2A or data processing system 220 of FIG. 2B. The operationbegins when a master 300 (e.g., a master 112 of an L2 cache 110 or amaster within an I/O controller 128) issues a request 302 on theinterconnect fabric. Request 302 preferably includes at least atransaction type indicating a type of desired access and a resourceidentifier (e.g., real address) indicating a resource to be accessed bythe request. Common types of requests preferably include those set forthbelow in Table I.

TABLE I Request Description READ Requests a copy of the image of amemory block for query purposes RWITM (Read-With- Requests a unique copyof the image of a memory block with the intent Intent-To-Modify) toupdate (modify) it and requires destruction of other copies, if anyDCLAIM (Data Requests authority to promote an existing query-only copyof memory Claim) block to a unique copy with the intent to update(modify) it and requires destruction of other copies, if any DCBZ (DataCache Requests authority to create a new unique copy of a memory blockBlock Zero) without regard to its present state and subsequently modifyits contents; requires destruction of other copies, if any CASTOUTCopies the image of a memory block from a higher level of memory to alower level of memory in preparation for the destruction of the higherlevel copy WRITE Requests authority to create a new unique copy of amemory block without regard to its present state and immediately copythe image of the memory block from a higher level memory to a lowerlevel memory in preparation for the destruction of the higher level copyPARTIAL WRITE Requests authority to create a new unique copy of apartial memory block without regard to its present state and immediatelycopy the image of the partial memory block from a higher level memory toa lower level memory in preparation for the destruction of the higherlevel copy

Further details regarding these operations and an exemplary cachecoherency protocol that facilitates efficient handling of theseoperations may be found in the copending U.S. patent application Ser.No. 11/055,305 incorporated by reference above.

Request 302 is received by snoopers 304, for example, snoopers 116 of L2caches 110 and snoopers 126 of IMCs 124, distributed throughout dataprocessing system 200. In general, with some exceptions, snoopers 116 inthe same L2 cache 110 as the master 112 of request 302 do not snooprequest 302 (i.e., there is generally no self-snooping) because arequest 302 is transmitted on the interconnect fabric only if therequest 302 cannot be serviced internally by a processing unit 100.Snoopers 304 that receive and process requests 302 each provide arespective partial response 306 representing the response of at leastthat snooper 304 to request 302. A snooper 126 within an IMC 124determines the partial response 306 to provide based, for example, uponwhether the snooper 126 is responsible for the request address andwhether it has resources available to service the request. A snooper 116of an L2 cache 110 may determine its partial response 306 based on, forexample, the availability of its L2 cache directory 114, theavailability of a snoop logic instance within snooper 116 to handle therequest, and the coherency state associated with the request address inL2 cache directory 114.

The partial responses 306 of snoopers 304 are logically combined eitherin stages or all at once by one or more instances of response logic 122to determine a combined response (CR) 310 to request 302. In onepreferred embodiment, which will be assumed hereinafter, the instance ofresponse logic 122 responsible for generating combined response 310 islocated in the processing unit 100 containing the master 300 that issuedrequest 302. Response logic 122 provides combined response 310 to master300 and snoopers 304 via the interconnect fabric to indicate theresponse (e.g., success, failure, retry, etc.) to request 302. If the CR310 indicates success of request 302, CR 310 may indicate, for example,a data source for a requested memory block, a cache state in which therequested memory block is to be cached by master 300, and whether“cleanup” operations invalidating the requested memory block in one ormore L2 caches 110 are required.

In response to receipt of combined response 310, one or more of master300 and snoopers 304 typically perform one or more operations in orderto service request 302. These operations may include supplying data tomaster 300, invalidating or otherwise updating the coherency state ofdata cached in one or more L2 caches 110, performing castout operations,writing back data to a system memory 132, etc. If required by request302, a requested or target memory block may be transmitted to or frommaster 300 before or after the generation of combined response 310 byresponse logic 122.

In the following description, the partial response 306 of a snooper 304to a request 302 and the operations performed by the snooper 304 inresponse to the request 302 and/or its combined response 310 will bedescribed with reference to whether that snooper is a Highest Point ofCoherency (HPC), a Lowest Point of Coherency (LPC), or neither withrespect to the request address specified by the request. An LPC isdefined herein as a memory device or I/O device that serves as therepository for a memory block. In the absence of a HPC for the memoryblock, the LPC holds the true image of the memory block and hasauthority to grant or deny requests to generate an additional cachedcopy of the memory block. For a typical request in the data processingsystem embodiment of FIGS. 1 and 2, the LPC will be the memorycontroller 124 for the system memory 132 holding the referenced memoryblock. An HPC is defined herein as a uniquely identified device thatcaches a true image of the memory block (which may or may not beconsistent with the corresponding memory block at the LPC) and has theauthority to grant or deny a request to modify the memory block.Descriptively, the HPC may also provide a copy of the memory block to arequestor in response to an operation that does not modify the memoryblock. Thus, for a typical request in the data processing systemembodiment of FIGS. 1 and 2, the HPC, if any, will be an L2 cache 110.Although other indicators may be utilized to designate an HPC for amemory block, a preferred embodiment of the present invention designatesthe HPC, if any, for a memory block utilizing selected cache coherencystate(s) within the L2 cache directory 114 of an L2 cache 110.

Still referring to FIG. 3, the HPC, if any, for a memory blockreferenced in a request 302, or in the absence of an HPC, the LPC of thememory block, preferably has the responsibility of protecting thetransfer of ownership of a memory block, if necessary, in response to arequest 302. In the exemplary scenario shown in FIG. 3, a snooper 304 nat the HPC (or in the absence of an HPC, the LPC) for the memory blockspecified by the request address of request 302 protects the transfer ofownership of the requested memory block to master 300 during aprotection window 312 a that extends from the time that snooper 304 ndetermines its partial response 306 until snooper 304 n receivescombined response 310 and during a subsequent window extension 312 bextending a programmable time beyond receipt by snooper 304 n ofcombined response 310. During protection window 312 a and windowextension 312 b, snooper 304 n protects the transfer of ownership byproviding partial responses 306 to other requests specifying the samerequest address that prevent other masters from obtaining ownership(e.g., a retry partial response) until ownership has been successfullytransferred to master 300. Master 300 likewise initiates a protectionwindow 313 to protect its ownership of the memory block requested inrequest 302 following receipt of combined response 310.

Because snoopers 304 all have limited resources for handling the CPU andI/O requests described above, several different levels of partialresponses and corresponding CRs are possible. For example, if a snooper126 within a memory controller 124 that is responsible for a requestedmemory block has a queue available to handle a request, the snooper 126may respond with a partial response indicating that it is able to serveas the LPC for the request. If, on the other hand, the snooper 126 hasno queue available to handle the request, the snooper 126 may respondwith a partial response indicating that is the LPC for the memory block,but is unable to currently service the request. Similarly, a snooper 116in an L2 cache 110 may require an available instance of snoop logic andaccess to L2 cache directory 114 in order to handle a request. Absenceof access to either (or both) of these resources results in a partialresponse (and corresponding CR) signaling an inability to service therequest due to absence of a required resource.

III. Broadcast Flow of Exemplary Operations

Referring now to FIG. 4A, there is illustrated a time-space diagram ofan exemplary operation flow of an operation of system-wide scope in dataprocessing system 200 of FIG. 2A. In these figures, the variousprocessing units 100 within data processing system 200 are tagged withtwo locational identifiers—a first identifying the processing node 202to which the processing unit 100 belongs and a second identifying theparticular processing unit 100 within the processing node 202. Thus, forexample, processing unit 100 a 0 c refers to processing unit 100 c ofprocessing node 202 a 0. In addition, each processing unit 100 is taggedwith a functional identifier indicating its function relative to theother processing units 100 participating in the operation. Thesefunctional identifiers include: (1) local master (LM), which designatesthe processing unit 100 that originates the operation, (2) local hub(LH), which designates a processing unit 100 that is in the sameprocessing node 202 as the local master and that is responsible fortransmitting the operation to another processing node 202 (a localmaster can also be a local hub), (3) remote hub (RH), which designates aprocessing unit 100 that is in a different processing node 202 than thelocal master and that is responsible to distribute the operation toother processing units 100 in its processing node 202, and (4) remoteleaf (RL), which designates a processing unit 100 that is in a differentprocessing node 202 from the local master and that is not a remote hub.

As shown in FIG. 4A, the exemplary operation has at least three phasesas described above with reference to FIG. 3, namely, a request (oraddress) phase, a partial response (Presp) phase, and a combinedresponse (Cresp) phase. These three phases preferably occur in theforegoing order and do not overlap. The operation may additionally havea data phase, which may optionally overlap with any of the request,partial response and combined response phases.

Still referring to FIG. 4A, the request phase begins when a local master100 a 0 c (i.e., processing unit 100 c of processing node 202 a 0)performs a synchronized broadcast of a request, for example, a readrequest, to each of the local hubs 100 a 0 a, 100 a 0 b, 100 a 0 c and100 a 0 d within its processing node 202 a 0. It should be noted thatthe list of local hubs includes local hub 100 a 0 c, which is also thelocal master. As described further below, this internal transmission isadvantageously employed to synchronize the operation of local hub 100 a0 c with local hubs 100 a 0 a, 100 a 0 b and 100 a 0 d so that thetiming constraints discussed below can be more easily satisfied.

In response to receiving the request, each local hub 100 that is coupledto a remote hub 100 by its A or B links transmits the operation to itsremote hub(s) 100. Thus, local hub 100 a 0 a makes no transmission ofthe operation on its outbound A link, but transmits the operation viaits outbound B link to a remote hub within processing node 202 a 1.Local hubs 100 a 0 b, 100 a 0 c and 100 a 0 d transmit the operation viatheir respective outbound A and B links to remote hubs in processingnodes 202 b 0 and 202 b 1, processing nodes 202 c 0 and 202 c 1, andprocessing nodes 202 d 0 and 202 d 1, respectively. Each remote hub 100receiving the operation in turn transmits the operation to each remoteleaf 100 in its processing node 202. Thus, for example, local hub 100 b0 a transmits the operation to remote leaves 100 b 0 b, 100 b 0 c and100 b 0 d. In this manner, the operation is efficiently broadcast to allprocessing units 100 within data processing system 200 utilizingtransmission over no more than three links.

Following the request phase, the partial response (Presp) phase occurs,as shown in FIG. 4A. In the partial response phase, each remote leaf 100evaluates the operation and provides its partial response to theoperation to its respective remote hub 100. For example, remote leaves100 b 0 b, 100 b 0 c and 100 b 0 d transmit their respective partialresponses to remote hub 100 b 0 a. Each remote hub 100 in turn transmitsthese partial responses, as well as its own partial response, to arespective one of local hubs 100 a 0 a, 100 a 0 b, 100 a 0 c and 100 a 0d. Local hubs 100 a 0 a, 100 a 0 b, 100 a 0 c and 100 a 0 d thenbroadcast these partial responses, as well as their own partialresponses, to each local hub 100 in processing node 202 a 0. It shouldbe noted that the broadcast of partial responses by the local hubs 100within processing node 202 a 0 includes, for timing reasons, theself-broadcast by each local hub 100 of its own partial response.

As will be appreciated, the collection of partial responses in themanner shown can be implemented in a number of different ways. Forexample, it is possible to communicate an individual partial responseback to each local hub from each other local hub, remote hub and remoteleaf. Alternatively, for greater efficiency, it may be desirable toaccumulate partial responses as they are communicated back to the localhubs. In order to ensure that the effect of each partial response isaccurately communicated back to local hubs 100, it is preferred that thepartial responses be accumulated, if at all, in a non-destructivemanner, for example, utilizing a logical OR function and an encoding inwhich no relevant information is lost when subjected to such a function(e.g., a “one-hot” encoding).

As further shown in FIG. 4A, response logic 122 at each local hub 100within processing node 202 a 0 compiles the partial responses of theother processing units 100 to obtain a combined response representingthe system-wide response to the request. Local hubs 100 a 0 a-100 a 0 dthen broadcast the combined response to all processing units 100following the same paths of distribution as employed for the requestphase. Thus, the combined response is first broadcast to remote hubs100, which in turn transmit the combined response to each remote leaf100 within their respective processing nodes 202. For example, remotehub 100 a 0 b transmits the combined response to remote hub 100 b 0 a,which in turn transmits the combined response to remote leaves 100 b 0b, 100 b 0 c and 100 b 0 d.

As noted above, servicing the operation may require an additional dataphase. For example, if the operation is a read-type operation, such as aread or RWITM operation, remote leaf 100 b 0 d may source the requestedmemory block to local master 100 a 0 c via the links connecting remoteleaf 100 b 0 d to remote hub 100 b 0 a, remote hub 100 b 0 a to localhub 100 a 0 b, and local hub 100 a 0 b to local master 100 a 0 c.Conversely, if the operation is a write-type operation, for example, acache castout operation writing a modified memory block back to thesystem memory 132 of remote leaf 100 b 0 b, the memory block istransmitted via the links connecting local master 100 a 0 c to local hub100 a 0 b, local hub 100 a 0 b to remote hub 100 b 0 a, and remote hub100 b 0 a to remote leaf 100 b 0 b.

Referring now to FIG. 4B, there is illustrated a time-space diagram ofan exemplary operation flow of an operation of node-only scope in dataprocessing system 200 of FIG. 2A. In these figures, the variousprocessing units 100 within data processing system 200 are tagged withtwo locational identifiers—a first identifying the processing node 202to which the processing unit 100 belongs and a second identifying theparticular processing unit 100 within the processing node 202. Thus, forexample, processing unit 100 b 0 a refers to processing unit 100 b ofprocessing node 202 b 0. In addition, each processing unit 100 is taggedwith a functional identifier indicating its function relative to theother processing units 100 participating in the operation. Thesefunctional identifiers include: (1) node master (NM), which designatesthe processing unit 100 that originates an operation of node-only scope,and (2) node leaf (NL), which designates a processing unit 100 that isin the same processing node 202 as the node master and that is not thenode master.

As shown in FIG. 4B, the exemplary node-only operation has at leastthree phases as described above: a request (or address) phase, a partialresponse (Presp) phase, and a combined response (Cresp) phase. Again,these three phases preferably occur in the foregoing order and do notoverlap. The operation may additionally have a data phase, which mayoptionally overlap with any of the request, partial response andcombined response phases.

Still referring to FIG. 4B, the request phase begins when a node master100 b 0 a (i.e., processing unit 100 a of processing node 202 b 0),which functions much like a remote hub in the operational scenario ofFIG. 4A, performs a synchronized broadcast of a request, for example, aread request, to each of the node leaves 100 b 0 b, 100 b 0 c, and 100 b0 d within its processing node 202 b 0. It should be noted that, becausethe scope of the broadcast transmission is limited to a single node, nointernal transmission of the request within node master 100 b 0 a isemployed to synchronize off-node transmission of the request.

Following the request phase, the partial response (Presp) phase occurs,as shown in FIG. 4B. In the partial response phase, each of node leaves100 b 0 b, 100 b 0 c and 100 b 0 d evaluates the operation and providesits partial response to the operation to node master 100 b 0 a. Next, asfurther shown in FIG. 4B, response logic 122 at node master 100 b 0 awithin processing node 202 b 0 compiles the partial responses of theother processing units 100 to obtain a combined response representingthe node-wide response to the request. Node master 100 b 0 a thenbroadcasts the combined response to all node leaves 100 b 0 b, 100 b 0 cand 1000 b 0 d utilizing the X, Y and Z links of node master 100 b 0 a.

As noted above, servicing the operation may require an additional dataphase. For example, if the operation is a read-type operation, such as aread or RWITM operation, node leaf 100 b 0 d may source the requestedmemory block to node master 100 b 0 a via the Z link connecting nodeleaf 100 b 0 d to node master 100 b 0 a. Conversely, if the operation isa write-type operation, for example, a cache castout operation writing amodified memory block back to the system memory 132 of remote leaf 100 b0 b, the memory block is transmitted via the X link connecting nodemaster 100 b 0 a to node leaf 100 b 0 b.

With reference now to FIG. 4C, which will be described in conjunctionwith FIGS. 5A-5E, there is illustrated a time-space diagram of anexemplary operation flow of an operation in data processing system 220of FIG. 2B. In these figures, the various processing units 100 withindata processing system 220 are tagged utilizing the same two locationalidentifiers described above. In addition, each processing unit 100 istagged with a functional identifier indicating its function relative tothe other processing units 100 participating in the operation. Thesefunctional identifiers include: (1) node master (NM), which designatesthe processing unit 100 that originates the operation, (2) node leaf(NL), which designates a processing unit 100 that is in the sameprocessing node 202 as the node master but is not the node master, (3)remote hub (RH), which designates a processing unit 100 that is in adifferent processing node 202 than the local master and that isresponsible for distributing the operation to other processing units 100in its processing node 202, and (4) remote leaf (RL), which designates aprocessing unit 100 that is in a different processing node 202 from thelocal master and that is not a remote hub.

As shown in FIG. 4C, the exemplary operation has at least three phasesas described above with reference to FIG. 3, namely, a request (oraddress) phase, a partial response (Presp) phase, and a combinedresponse (Cresp) phase. These three phases preferably occur in theforegoing order and do not overlap. The operation may additionally havea data phase, which may optionally overlap with any of the request,partial response and combined response phases.

Still referring to FIG. 4C and referring additionally to FIG. 5A, therequest phase begins when a node master (NM) 100 a 0 c (i.e., processingunit 100 c of processing node 202 a 0) performs a synchronized broadcastof a request, for example, a read request, to each of the node leaves100 a 0 a, 100 a 0 b, and 100 a 0 d within its processing node 202 a 0and to remote hub 100 b 0 d in processing node 202 b 0. Remote hub 100 b0 d in turn transmits the operation to each of remote leaves 100 b 0 a,100 b 0 b and 100 b 0 c. In this manner, the operation is efficientlybroadcast to all processing units 100 within data processing system 200utilizing transmission over no more than two links.

Following the request phase, the partial response (Presp) phase occurs,as shown in FIGS. 4A and 5B. In the partial response phase, each remoteleaf 100 evaluates the operation and provides its respective partialresponse for the operation to its respective remote hub 100. Forexample, remote leaves 100 b 0 a, 100 b 0 c and 100 b 0 c transmit theirrespective partial responses to remote hub 100 b 0 d. Each remote hub100 in turn transmits these partial responses, as well as its ownpartial response, to node master 100 a 0 c. Each of node leaves 100 a 0a, 100 a 0 b and 100 a 0 d similarly evaluates the request and transmitsits respective partial response to node master 100 a 0 c.

As will be appreciated, the collection of partial responses in themanner shown can be implemented in a number of different ways. Forexample, it is possible to communicate an individual partial responseback to the node master from each other node leaf, remote hub and remoteleaf. Alternatively, for greater efficiency, it may be desirable toaccumulate partial responses as they are communicated back to theoriginating processing node. In order to ensure that the effect of eachpartial response is accurately communicated back to node master 100, itis preferred that the partial responses be accumulated, if at all, in anon-destructive manner, for example, utilizing a logical OR function andan encoding in which no relevant information is lost when subjected tosuch a function (e.g., a “one-hot” encoding).

As further shown in FIG. 4A and FIG. 5C, response logic 122 at nodemaster 100 a 0 c compiles the partial responses of the other processingunits 100 to obtain a combined response representing the system-wideresponse to the request. Node master 100 a 0 c then broadcasts thecombined response to all processing units 100 following the same pathsof distribution as employed for the request phase. Thus, the combinedresponse is first broadcast to node leaves 100 a 0 a, 100 a 0 b and 100a 0 d and remote hub 100 b 0 d. Remote hub 100 b 0 d in turn transmitsthe combined response to each of remote leaves 100 b 0 a, 100 b 0 b and100 b 0 c.

As noted above, servicing the operation may require an additional dataphase, such as shown in FIG. 5D or 5E. For example, as shown in FIG. 5D,if the operation is a read-type operation, such as a read or RWITMoperation, remote leaf 100 b 0 b may source the requested memory blockto node master 100 a 0 c via the links connecting remote leaf 100 b 0 bto node leaf 100 a 0 a and node leaf 100 a 0 a to local master 100 a 0c. Conversely, if the operation is a write-type operation, for example,a cache castout operation writing a modified memory block back to thesystem memory 132 of remote leaf 100 b 0 d, the memory block istransmitted via the link connecting node master 100 a 0 c to remote hub100 b 0 d, as shown in FIG. 5E.

Of course, the operations depicted in FIGS. 4A-4C are merely exemplaryof the myriad of possible operations that may occur concurrently in amultiprocessor data processing system such as data processing system 200or data processing system 220.

IV. Timing Considerations

As described above with reference to FIG. 3, coherency is maintainedduring the “handoff” of coherency ownership of a memory block from asnooper 304 n to a requesting master 300 in the possible presence ofother masters competing for ownership of the same memory block throughprotection window 312 a, window extension 312 b, and protection window313. For example, as shown in FIG. 6, protection window 312 a and windowextension 312 b must together be of sufficient duration to protect thetransfer of coherency ownership of the requested memory block fromsnooper 304 n to winning master (WM) 300 in the presence of a competingrequest 322 by a competing master (CM) 320. To ensure that protectionwindow 312 a and window extension 312 b have sufficient duration toprotect the transfer of ownership of the requested memory block fromsnooper 304 n to winning master 300, the latency of communicationbetween processing units 100 in accordance with FIGS. 4A, 4B and 4C ispreferably constrained such that the following conditions are met:A_lat(CM_(—) S)≦A_lat(CM_WM)+C_lat(WM_(—) S)+ε,where A_lat(CM_S) is the address latency of any competing master (CM)320 to the snooper (S) 304 n owning coherence of the requested memoryblock, A_lat(CM_WM) is the address latency of any competing master (CM)320 to the “winning” master (WM) 300 that is awarded coherency ownershipby snooper 304 n, C_lat(WM_S) is the combined response latency from thetime that the combined response is received by the winning master (WM)300 to the time the combined response is received by the snooper (S) 304n owning the requested memory block, and ε is the duration of windowextension 312 b.

If the foregoing timing constraint, which is applicable to a system ofarbitrary topology, is not satisfied, the request 322 of the competingmaster 320 may be received (1) by winning master 300 prior to winningmaster 300 assuming coherency ownership and initiating protection window312 b and (2) by snooper 304 n after protection window 312 a and windowextension 312 b end. In such cases, neither winning master 300 norsnooper 304 n will provide a partial response to competing request 322that prevents competing master 320 from assuming coherency ownership ofthe memory block and reading non-coherent data from memory. However, toavoid this coherency error, window extension 312 b can be programmablyset (e.g., by appropriate setting of configuration register 123) to anarbitrary length (ε) to compensate for latency variations or theshortcomings of a physical implementation that may otherwise fail tosatisfy the timing constraint that must be satisfied to maintaincoherency. Thus, by solving the above equation for ε, the ideal lengthof window extension 312 b for any implementation can be determined. Forthe data processing system embodiments of FIGS. 2A and 2B, it ispreferred if ε has a duration equal to the latency of one first tierlink chip-hop for broadcast operations having a scope including multipleprocessing nodes 202 and has a duration of zero for operations ofnode-only scope.

Several observations may be made regarding the foregoing timingconstraint. First, the address latency from the competing master 320 tothe owning snooper 304 a has no necessary lower bound, but must have anupper bound. The upper bound is designed for by determining the worstcase latency attainable given, among other things, the maximum possibleoscillator drift, the longest links coupling processing units 100, themaximum number of accumulated stalls, and guaranteed worst casethroughput. In order to ensure the upper bound is observed, theinterconnect fabric must ensure non-blocking behavior.

Second, the address latency from the competing master 320 to the winningmaster 300 has no necessary upper bound, but must have a lower bound.The lower bound is determined by the best case latency attainable,given, among other things, the absence of stalls, the shortest possiblelink between processing units 100 and the slowest oscillator drift givena particular static configuration.

Although for a given operation, each of the winning master 300 andcompeting master 320 has only one timing bound for its respectiverequest, it will be appreciated that during the course of operation anyprocessing unit 100 may be a winning master for some operations and acompeting (and losing) master for other operations. Consequently, eachprocessing unit 100 effectively has an upper bound and a lower bound forits address latency.

Third, the combined response latency from the time that the combinedresponse is generated to the time the combined response is observed bythe winning master 300 has no necessary lower bound (the combinedresponse may arrive at the winning master 300 at an arbitrarily earlytime), but must have an upper bound. By contrast, the combined responselatency from the time that a combined response is generated until thecombined response is received by the snooper 304 n has a lower bound,but no necessary upper bound (although one may be arbitrarily imposed tolimit the number of operations concurrently in flight).

Fourth, there is no constraint on partial response latency. That is,because all of the terms of the timing constraint enumerated abovepertain to request/address latency and combined response latency, thepartial response latencies of snoopers 304 and competing master 320 towinning master 300 have no necessary upper or lower bounds.

V. Exemplary Link Information Allocation

The first tier and second tier links connecting processing units 100 maybe implemented in a variety of ways to obtain the topologies depicted inFIGS. 2A and 2B and to meet the timing constraints illustrated in FIG.6. In one preferred embodiment, each inbound and outbound first tier (X,Y and Z) link and each inbound and outbound second tier (A and B) linkis implemented as a uni-directional 8-byte bus containing a number ofdifferent virtual channels or tenures to convey address, data, controland coherency information.

With reference now to FIGS. 7A-7B, there is illustrated a firstexemplary time-sliced information allocation for the first tier X, Y andZ links and second tier A and B links. As shown, in this firstembodiment information is allocated on the first and second tier linksin a repeating 8 cycle frame in which the first 4 cycles comprise twoaddress tenures transporting address, coherency and control informationand the second 4 cycles are dedicated to a data tenure providing datatransport.

Reference is first made to FIG. 7A, which illustrates the linkinformation allocation for the first tier links. In each cycle in whichthe cycle number modulo 8 is 0, byte 0 communicates a transaction type700 a (e.g., a read) of a first operation, bytes 1-5 provide the 5 loweraddress bytes 702 a 1 of the request address of the first operation, andbytes 6-7 form a reserved field 704. In the next cycle (i.e., the cyclefor which cycle number modulo 8 is 1), bytes 0-1 communicate a mastertag 706 a identifying the master 300 of the first operation (e.g., oneof L2 cache masters 112 or a master within I/O controller 128), and byte2 conveys the high address byte 702 a 2 of the request address of thefirst operation. Communicated together with this information pertainingto the first operation are up to three additional fields pertaining todifferent operations, namely, a local partial response 708 a intendedfor a local master in the same processing node 202 (bytes 3-4), acombined response 710 a in byte 5, and a remote partial response 712 aintended for a local master in a different processing node 202 (or inthe case of a node-only broadcast, the partial response communicatedfrom the node leaf 100 to node master 100) (bytes 6-7). As noted above,these first two cycles form what is referred to herein as an addresstenure.

As further illustrated in FIG. 7A, the next two cycles (i.e., the cyclesfor which the cycle number modulo 8 is 2 and 3) form a second addresstenure having the same basic pattern as the first address tenure, withthe exception that reserved field 704 is replaced with a data tag 714and data token 715 forming a portion of the data tenure. Specifically,data tag 714 identifies the destination data sink to which the 32 bytesof data payload 716 a-716 d appearing in cycles 4-7 are directed. Itslocation within the address tenure immediately preceding the payloaddata advantageously permits the configuration of downstream steering inadvance of receipt of the payload data, and hence, efficient datarouting toward the specified data sink. Data token 715 provides anindication that a downstream queue entry has been freed and,consequently, that additional data may be transmitted on the paired X,Y, Z or A link without risk of overrun. Again it should be noted thattransaction type 700 b, master tag 706 b, low address bytes 702 b 1, andhigh address byte 702 b 2 all pertain to a second operation, and datatag 714, local partial response 708 b, combined response 710 b andremote partial response 712 b all relate to one or more operations otherthan the second operation.

Each transaction type field 700 and combined response field 710preferably includes a scope indicator 730 capable of indicating whetherthe operation to which it belongs has a node-only (local) or system-wide(global) scope. When configuration register 123 is set to configureprocessing units 100 in a supernode mode, scope indicator 730 is unusedand has a “don't care” value. As described in greater detail incross-referenced U.S. patent application Ser. No. 11/055,305, which isincorporated by reference above, data tag 714 further includes a domainindicator 732 that may be set by the LPC to indicate whether or not aremote copy of the data contained within data payload 716 a-716 d mayexist. Preferably, when configuration register 123 is set to configureprocessing units 100 in a supernode mode, domain indicator 732 is alsounused and has a “don't care” value.

FIG. 7B depicts the link information allocation for the second tier Aand B links. As can be seen by comparison with FIG. 7A, the linkinformation allocation on the second tier A and B links is the same asthat for the first tier links given in FIG. 7A, except that localpartial response fields 708 a, 708 b are replaced with reserved fields718 a, 718 b. This replacement is made for the simple reason that, as asecond tier link, no local partial responses need to be communicated.

FIG. 7C illustrates an exemplary embodiment of a write request partialresponse 720, which may be transported within either a local partialresponse field 708 a, 708 b or a remote partial response field 712 a,712 b in response to a write request. As shown, write request partialresponse 720 is two bytes in length and includes a 15-bit destinationtag field 724 for specifying the tag of a snooper (e.g., an IMC snooper126) that is the destination for write data and a 1-bit valid (V) flag722 for indicating the validity of destination tag field 724.

VI. Request Phase Structure and Operation

Referring now to FIG. 8, there is depicted a block diagram illustratingrequest logic 121 a within interconnect logic 120 of FIG. 1 utilized inrequest phase processing of an operation. As shown, request logic 121 aincludes a master multiplexer 900 coupled to receive requests by themasters 300 of a processing unit 100 (e.g., masters 112 within L2 cache110 and masters within I/O controller 128). The output of mastermultiplexer 900 forms one input of a request multiplexer 904. The secondinput of request multiplexer 904 is coupled to the output of a remotehub multiplexer 903 having its inputs coupled to the outputs of holdbuffers 902 a, 902 b, which are in turn coupled to receive and bufferrequests on the inbound A and B links, respectively. Remote hubmultiplexer 903 implements a fair allocation policy, described furtherbelow, that fairly selects among the requests received from the inboundA and B links that are buffered in hold buffers 902 a-902 b. If present,a request presented to request multiplexer 904 by remote hub multiplexer903 is always given priority by request multiplexer 904. The output ofrequest multiplexer 904 drives a request bus 905 that is coupled to eachof the outbound X, Y and Z links, a node master/remote hub (NMR-H) holdbuffer 906, and the local hub (LH) address launch buffer 910. A previousrequest FIFO buffer 907, which is also coupled to request bus 905,preferably holds a small amount of address-related information for eachof a number of previous address tenures to permit a determination of theaddress slice or resource bank 1912 to which the address, if any,communicated in that address tenure hashes. For example, in oneembodiment, each entry of previous request FIFO buffer 907 contains a“1-hot” encoding identifying a particular one of banks 1912 a-1912 n towhich the request address of an associated request hashed. For addresstenures in which no request is transmitted on request bus 905, the 1-hotencoding would be all ‘0’s.

The inbound first tier (X, Y and Z) links are each coupled to the LHaddress launch buffer 910, as well as a respective one of nodeleaf/remote leaf (NL/RL) hold buffers 914 a-914 c. The outputs of NM/RHhold buffer 906, LH address launch buffer 910, and NL/RL hold buffers914 a-914 c all form inputs of a snoop multiplexer 920. Coupled to theoutput of LH address launch buffer 910 is another previous buffer 911,which is preferably constructed like previous request FIFO buffer 907.The output of snoop multiplexer 920 drives a snoop bus 922 to which tagFIFO queues 924, the snoopers 304 (e.g., snoopers 116 of L2 cache 110and snoopers 126 of IMC 124) of the processing unit 100, and theoutbound A and B links are coupled. Snoopers 304 are further coupled toand supported by local hub (LH) partial response FIFO queues 930 andnode master/remote hub (NM/RH) partial response FIFO queue 940.

Although other embodiments are possible, it is preferable if buffers902, 906, and 914 a-914 c remain short in order to minimizecommunication latency. In one preferred embodiment, each of buffers 902,906, and 914 a-914 c is sized to hold only the address tenure(s) of asingle frame of the selected link information allocation.

With reference now to FIG. 9, there is illustrated a more detailed blockdiagram of local hub (LH) address launch buffer 910 of FIG. 8. Asdepicted, the local and inbound X, Y and Z link inputs of the LH addresslaunch buffer 910 form inputs of a map logic 1010, which places requestsreceived on each particular input into a respective correspondingposition-dependent FIFO queue 1020 a-1020 d. In the depictednomenclature, the processing unit 100 a in the upper left-hand corner ofa processing node/MCM 202 is the “S” chip; the processing unit 100 b inthe upper right-hand corner of the processing node/MCM 202 is the “T”chip; the processing unit 100 c in the lower left-hand corner of aprocessing node/MCM 202 is the “U” chip; and the processing unit 100 din the lower right-hand corner of the processing node 202 is the “V”chip. Thus, for example, for local master/local hub 100 ac, requestsreceived on the local input are placed by map logic 1010 in U FIFO queue1020 c, and requests received on the inbound Y link are placed by maplogic 1010 in S FIFO queue 1020 a. Map logic 1010 is employed tonormalize input flows so that arbitration logic 1032, described below,in all local hubs 100 is synchronized to handle requests identicallywithout employing any explicit inter-communication.

Although placed within position-dependent FIFO queues 1020 a-1020 d,requests are not immediately marked as valid and available for dispatch.Instead, the validation of requests in each of position-dependent FIFOqueues 1020 a-1020 d is subject to a respective one of programmabledelays 1000 a-1000 d in order to synchronize the requests that arereceived during each address tenure on the four inputs. Thus, theprogrammable delay 1000 a associated with the local input, whichreceives the request self-broadcast at the local master/local hub 100,is generally considerably longer than those associated with the otherinputs. In order to ensure that the appropriate requests are validated,the validation signals generated by programmable delays 1000 a-1000 dare subject to the same mapping by map logic 1010 as the underlyingrequests.

The outputs of position-dependent FIFO queues 1020 a-1020 d form theinputs of local hub request multiplexer 1030, which selects one requestfrom among position-dependent FIFO queues 1020 a-1020 d for presentationto snoop multiplexer 920 in response to a select signal generated byarbiter 1032. Arbiter 1032 implements a fair arbitration policy that issynchronized in its selections with the arbiters 1032 of all other localhubs 100 within a given processing node 202 so that the same request isbroadcast on the outbound A links at the same time by all local hubs 100in a processing node 202, as depicted in FIGS. 4 and 5A. Thus, giveneither of the exemplary link information allocation shown in FIGS. 7Band 8B, the output of local hub request multiplexer 1030 istimeslice-aligned to the address tenure(s) of an outbound A link requestframe.

Because the input bandwidth of LH address launch buffer 910 is fourtimes its output bandwidth, overruns of position-dependent FIFO queues1020 a-1020 d are a design concern. In a preferred embodiment, queueoverruns are prevented by implementing, for each position-dependent FIFOqueue 1020, a pool of local hub tokens equal in size to the depth of theassociated position-dependent FIFO queue 1020. A free local hub token isrequired for a local master to send a request to a local hub andguarantees that the local hub can queue the request. Thus, a local hubtoken is allocated when a request is issued by a local master 100 to aposition-dependent FIFO queue 1020 in the local hub 100 and freed forreuse when arbiter 1032 issues an entry from the position-dependent FIFOqueue 1020.

Referring now to FIG. 10, there is depicted a more detailed blockdiagram of tag FIFO queues 924 of FIG. 8. As shown, tag FIFO queues 924include a local hub (LH) tag FIFO queue 924 a, remote hub (RH) tag FIFOqueues 924 b 0-924 b 1, node master (NM) tag FIFO queue 924 b 2, remoteleaf (RL) tag FIFO queues 924 c 0-924 c 1, 924 d 0-924 d 1 and 924 e0-924 e 1, and node leaf (NL) tag FIFO queues 924 c 2, 924 d 2 and 924 e2. The master tag of a request of an operation of system-wide scope isdeposited in each of tag FIFO queues 924 a, 924 b 0-924 b 1, 924 c 0-924c 1, 924 d 0-924 d 1 and 924 e 0-924 e 1 when the request is received atthe processing unit(s) 100 serving in each of these given roles (LH, RH,and RL) for that particular request. Similarly, the master tag of arequest of an operation of node-only scope is deposited in each of tagFIFO queues 924 b 2, 924 c 2, 924 d 2 and 924 e 2 when the request isreceived at the processing unit(s) 100 serving in each of these givenroles (NM and NL) for that particular request. The master tag isretrieved from each of tag FIFO queues 924 when the combined response isreceived at the associated processing unit 100. Thus, rather thantransporting the master tag with the combined response, master tags areretrieved by a processing unit 100 from its tag FIFO queue 924 asneeded, resulting in bandwidth savings on the first and second tierlinks. Given that the order in which a combined response is received atthe various processing units 100 is identical to the order in which theassociated request was received, a FIFO policy for allocation andretrieval of the master tag can advantageously be employed.

LH tag FIFO queue 924 a includes a number of entries, each including amaster tag field 1100 for storing the master tag of a request launchedby arbiter 1032. Each of tag FIFO queues 924 b 0-924 b 1 similarlyincludes multiple entries, each including at least a master tag field1100 for storing the master tag of a request of system-wide scopereceived by a remote hub 100 via a respective one of the inbound A and Blinks. Tag FIFO queues 924 c 0-924 c 1, 924 d 0-924 d 1 and 924 e 0-924e 1 are similarly constructed and each hold master tags of requests ofsystem-wide scope received by a remote leaf 100 via a unique pairing ofinbound first and second tier links. For requests of node-only broadcastscope, NM tag FIFO queues 924 b 2 holds the master tags of requestsoriginated by the node master 100, and each of NL tag FIFO queues 924 c2, 924 d 2 and 924 e 2 provides storage for the master tags of requestsreceived by a node leaf 100 on a respective one of the first tier X, Yand Z links.

Entries within LH tag FIFO queue 924 a have the longest tenures forsystem-wide broadcast operations, and NM tag FIFO queue 924 b 2 have thelongest tenures for node-only broadcast operations. Consequently, thedepths of LH tag FIFO queue 924 a and NM tag FIFO queue 924 b 2respectively limit the number of concurrent operations of system-widescope that a processing node 202 can issue on the interconnect fabricand the number of concurrent operations of node-only scope that a givenprocessing unit 100 can issue on the interconnect fabric. These depthshave no necessary relationship and may be different. However, the depthsof tag FIFO queues 924 b 0-924 b 1, 924 c 0-924 c 1, 924 d 0-924 d 1 and924 e 0-924 e 1 are preferably designed to be equal to that of LH tagFIFO queue 924 a, and the depths of tag FIFO queues 924 c 2, 924 d 2 and924 e 2 are preferably designed to be equal to that of NM tag FIFO queue924 b 2.

With reference now to FIGS. 11 and 12, there are illustrated moredetailed block diagrams of exemplary embodiments of the local hub (LH)partial response FIFO queue 930 and node master/remote hub (NM/RH)partial response FIFO queue 940 of FIG. 8. As indicated, LH partialresponse FIFO queue 930 includes a number of entries 1200 that eachincludes a partial response field 1202 for storing an accumulatedpartial response for a request and a response flag array 1204 havingrespective flags for each of the 6 possible sources from which the localhub 100 may receive a partial response (i.e., local (L), first tier X,Y, Z links, and second tier A and B links) at different times orpossibly simultaneously. Entries 1200 within LH partial response FIFOqueue 930 are allocated via an allocation pointer 1210 and deallocatedvia a deallocation pointer 1212. Various flags comprising response flagarray 1204 are accessed utilizing A pointer 1214, B pointer 1215, Xpointer 1216, Y pointer 1218, and Z pointer 1220.

As described further below, when a partial response for a particularrequest is received by partial response logic 121 b at a local hub 100,the partial response is accumulated within partial response field 1202,and the link from which the partial response was received is recorded bysetting the corresponding flag within response flag array 1204. Thecorresponding one of pointers 1214, 1215, 1216, 1218 and 1220 is thenadvanced to the subsequent entry 1200.

Of course, as described above, each processing unit 100 need not befully coupled to other processing units 100 by each of its 5 inbound (X,Y, Z, A and B) links. Accordingly, flags within response flag array 1204that are associated with unconnected links are ignored. The unconnectedlinks, if any, of each processing unit 100 may be indicated, forexample, by the configuration indicated in configuration register 123,which may be set, for example, by boot code at system startup or by theoperating system when partitioning data processing system 200.

As can be seen by comparison of FIG. 12 and FIG. 11, NM/RH partialresponse FIFO queue 940 is constructed similarly to LH partial responseFIFO queue 930. NM/RH partial response FIFO queue 940 includes a numberof entries 1230 that each includes a partial response field 1202 forstoring an accumulated partial response and a response flag array 1234having respective flags for each of the up to 4 possible sources fromwhich the node master or remote hub 100 may receive a partial response(i.e., node master (NM)/remote (R), and first tier X, Y, and Z links).In addition, each entry 1230 includes a route field 1236 identifyingwhether the operation is a node-only or system-wide broadcast operationand, for system-wide broadcast operations, which of the inbound secondtier links the request was received upon (and thus which of the outboundsecond tier links the accumulated partial response will be transmittedon). Entries 1230 within NM/RH partial response FIFO queue 940 areallocated via an allocation pointer 1210 and deallocated via adeallocation pointer 1212. Various flags comprising response flag array1234 are accessed and updated utilizing X pointer 1216, Y pointer 1218,and Z pointer 1220.

As noted above with respect to FIG. 11, each processing unit 100 neednot be fully coupled to other processing units 100 by each of its firsttier X, Y, and Z links. Accordingly, flags within response flag array1204 that are associated with unconnected links are ignored. Theunconnected links, if any, of each processing unit 100 may be indicated,for example, by the configuration indicated in configuration register123.

With reference now to FIGS. 13A-13D, flowcharts are given thatrespectively depict exemplary processing of an operation during therequest phase at a local master (or node master), local hub, remote hub(or node master), and remote leaf (or node leaf) in accordance with anexemplary embodiment of the present invention. Referring nowspecifically to FIG. 13A, request phase processing at the local master(or node master, if a node-only or supernode broadcast) 100 begins atblock 1400 with the generation of a request by a particular master 300(e.g., one of masters 112 within an L2 cache 110 or a master within anI/O controller 128) within a local (or node) master 100. Following block1400, the process proceeds to blocks 1402, 1404, 1406, and 1408, each ofwhich represents a condition on the issuance of the request by theparticular master 300. The conditions illustrated at blocks 1402 and1404 represent the operation of master multiplexer 900, and theconditions illustrated at block 1406 and 1408 represent the operation ofrequest multiplexer 904.

Turning first to blocks 1402 and 1404, master multiplexer 900 outputsthe request of the particular master 300 if the fair arbitration policygoverning master multiplexer 900 selects the request of the particularmaster 300 from the requests of (possibly) multiple competing masters300 (block 1402) and, if the request is a system-wide broadcast, if alocal hub token is available for assignment to the request (block 1404).As indicated by block 1415, if the master 300 selects the scope of itsrequest to have a node-only or supernode scope (for example, byreference to a setting of configuration register 123 and/or a scopeprediction mechanism, such as that described in above-referenced U.S.patent application Ser. No. 11/055,305, no local hub token is required,and the condition illustrated at block 1404 is omitted.

Assuming that the request of the particular master 300 progressesthrough master multiplexer 900 to request multiplexer 904, requestmultiplexer 904 issues the request on request bus 905 only if a addresstenure is then available for a request in the outbound first tier linkinformation allocation (block 1406). That is, the output of requestmultiplexer 904 is timeslice aligned with the selected link informationallocation and will only generate an output during cycles designed tocarry a request (e.g., cycle 0 or 2 of the embodiment of FIG. 7A). Asfurther illustrated at block 1408, request multiplexer 904 will onlyissue a request if no request from the inbound second tier A and B linksis presented by remote hub multiplexer 903 (block 1406), which is alwaysgiven priority. Thus, the second tier links are guaranteed to benon-blocking with respect to inbound requests. Even with such anon-blocking policy, requests by masters 300 can prevented from“starving” through implementation of an appropriate policy in thearbiter 1032 of the upstream hubs that prevents “brickwalling” ofrequests during numerous consecutive address tenures on the inbound Aand B link of the downstream hub.

If a negative determination is made at any of blocks 1402-1408, therequest is delayed, as indicated at block 1410, until a subsequent cycleduring which all of the determinations illustrated at blocks 1402-1408are positive. If, on the other hand, positive determinations are made atall of blocks 1402-1408, the process proceeds to block 1417. Block 1417represents that requests of node-only scope (as indicated by scopeindicator 730 of Ttype field 700) or supernode scope (as indicated byconfiguration register 123) are subject to additional conditions.

First, as shown at block 1419, if the request is a node-only orsupernode broadcast request, request multiplexer 904 will issue therequest only if an entry is available for allocation to the request inNM tag FIFO queue 924 b 2. If not, the process passes from block 1419 toblock 1410, which has been described.

Second, as depicted at block 1423, in the depicted embodiment requestmultiplexer 904 will issue a request of node-only or supernode scopeonly if the request address does not hash to the same bank 1912 of abanked resource 1910 as any of a selected number of prior requestsbuffered within previous request FIFO buffer 907. For example, assumingthat a snooping device 1900 and its associated resource 1910 areconstructed so that snooping device 1900 cannot service requests at themaximum request arrival rate, but can instead service requests at afraction of the maximum arrival rate expressed as 1/R, the selectednumber of prior requests with which the current node-only request vyingfor launch by request multiplexer 904 is compared to determine if itfalls in the same address slice is preferably R−1. If multiple differentsnooping devices 1900 are to be protected in this manner from requestoverrun, the selected number of requests R−1 is preferably set to themaximum of the set of quantities R−1 calculated for the individualsnooping devices 1900. Because processing units 100 preferably do notcoordinate their selection of requests for broadcast, the throttling ofrequests in the manner illustrated at block 1423 does not guarantee thatthe arrival rate of requests at a particular snooping device 1900 willnot exceed the service rate of the snooping device 1900. However, thethrottling of node-only broadcast requests in the manner shown willlimit the number of requests that can arrive in a given number ofcycles, which can be expressed as:throttled_arr_rate=PU requests per R cycleswhere PU is the number of processing units 100 per processing node 202.Snooping devices 1900 are preferably designed to handle node-onlybroadcast requests arriving at such a throttled arrival rate withoutretry.

If the condition shown at block 1423 is not satisfied, the processpasses from block 1423 to block 1410, which has been described. If bothof the conditions illustrated at blocks 1419 and 1423 are satisfied,request multiplexer 904 issues the request on request bus 905 if therequest is of node-only scope, and the process passes through pageconnector 1425 to block 1427 of FIG. 13C. If, on the other hand, therequest is of supernode scope as determined at block 1401, requestmultiplexer 904 issues the request only if it determines that it has notbeen outputting too many requests in successive address tenures.Specifically, at shown at block 1403, to avoid starving out incomingrequests on the A and/or B links, request multiplexer 904 launchesrequests by masters 300 during no more than half (i.e., 1/t2) of theavailable address tenures. If the condition depicted at block 1401 issatisfied, request multiplexer 904 issues the supernode request onrequest bus 905, and the process passes through page connector 1425 toblock 1427 of FIG. 13C. If the condition depicted at block 1401 is notsatisfied, the process passes from block 1423 to block 1410, which hasbeen described.

Returning again to block 1417, if the request is system-wide broadcastrequest rather than a node-only or supernode broadcast request, theprocess proceeds to block 1412. Block 1412 depicts request multiplexer904 broadcasting the request on request bus 905 to each of the outboundX, Y and Z links and to the local hub address launch buffer 910.Thereafter, the process bifurcates and passes through page connectors1414 and 1416 to FIG. 13B, which illustrates the processing of therequest at each of the local hubs 100.

With reference now to FIG. 13B, processing of a system-wide request atthe local hub 100 that is also the local master 100 is illustratedbeginning at block 1416, and processing of the request at each of theother local hubs 100 in the same processing node 202 as the local master100 is depicted beginning at block 1414. Turning first to block 1414,requests received by a local hub 100 on the inbound X, Y and Z links arereceived by LH address launch buffer 910. As depicted at block 1420 andin FIG. 9, map logic 1010 maps each of the X, Y and Z requests to theappropriate ones of position-dependent FIFO queues 1020 a-1020 d forbuffering. As noted above, requests received on the X, Y and Z links andplaced within position-dependent queues 1020 a-1020 d are notimmediately validated. Instead, the requests are subject to respectiveones of tuning delays 1000 a-1000 d, which synchronize the handling ofthe X, Y and Z requests and the local request on a given local hub 100with the handling of the corresponding requests at the other local hubs100 in the same processing node 202 (block 1422). Thereafter, as shownat block 1430, the tuning delays 1000 validate their respective requestswithin position-dependent FIFO queues 1020 a-1020 d.

Referring now to block 1416, at the local master/local hub 100, therequest on request bus 905 is fed directly into LH address launch buffer910. Because no inter-chip link is traversed, this local request arrivesat LH address launch FIFO 910 earlier than requests issued in the samecycle arrive on the inbound X, Y and Z links. Accordingly, following themapping by map logic 1010, which is illustrated at block 1424, one oftuning delays 1000 a-100 d applies a long delay to the local request tosynchronize its validation with the validation of requests received onthe inbound X, Y and Z links (block 1426). Following this delayinterval, the relevant tuning delay 1000 validates the local request, asshown at block 1430.

Following the validation of the requests queued within LH address launchbuffer 910 at block 1430, the process then proceeds to blocks 1434-1440,each of which represents a condition on the issuance of a request fromLH address launch buffer 910 enforced by arbiter 1032. As noted above,the arbiters 1032 within all processing units 100 are synchronized sothat the same decision is made by all local hubs 100 withoutinter-communication. As depicted at block 1434, an arbiter 1032 permitslocal hub request multiplexer 1030 to output a request only if anaddress tenure is then available for the request in the outbound secondtier link information allocation. Thus, for example, arbiter 1032 causeslocal hub request multiplexer 1030 to initiate transmission of requestsonly during cycle 0 or 2 of the embodiment of FIG. 7B. In addition, arequest is output by local hub request multiplexer 1030 if the fairarbitration policy implemented by arbiter 1032 determines that therequest belongs to the position-dependent FIFO queue 1020 a-1020 d thatshould be serviced next (block 1436).

As depicted further at blocks 1437 and 1438, arbiter 1032 causes localhub request multiplexer 1030 to output a request only if it determinesthat it has not been outputting too many requests in successive addresstenures. Specifically, at shown at block 1437, to avoid overdriving therequest buses 905 of the hubs 100 connected to the outbound A and Blinks, arbiter 1032 assumes the worst case (i.e., that the upstream hub100 connected to the other second tier link of the downstream hub 100 istransmitting a request in the same cycle) and launches requests duringno more than half (i.e., 1/t2) of the available address tenures. Inaddition, as depicted at block 1438, arbiter 1032 further restricts thelaunch of requests below a fair allocation of the traffic on the secondtier links to avoid possibly “starving” the masters 300 in theprocessing units 100 coupled to its outbound A and B links.

For example, given the embodiment of FIG. 2A, where there are 2 pairs ofsecond tier links and 4 processing units 100 per processing node 202,traffic on the request bus 905 of the downstream hub 100 is subject tocontention by up to 9 processing units 100, namely, the 4 processingunits 100 in each of the 2 processing nodes 202 coupled to thedownstream hub 100 by second tier links and the downstream hub 100itself. Consequently, an exemplary fair allocation policy that dividesthe bandwidth of request bus 905 evenly among the possible requestsources allocates 4/9 of the bandwidth to each of the inbound A and Blinks and 1/9 of the bandwidth to the local masters 300. Generalizingfor any number of first and second tier links, the fraction of theavailable address frames allocated consumed by the exemplary fairallocation policy employed by arbiter 1032 can be expressed as:fraction=(t1/2+1)/(t2/2*(t1/2+1)+1)where t1 and t2 represent the total number of first and second tierlinks to which a processing unit 100 may be coupled, the quantity“t1/2+1” represents the number of processing units 100 per processingnode 202, the quantity “t2/2” represents the number of processing nodes202 to which a downstream hub 100 may be coupled, and the constantquantity “1” represents the fractional bandwidth allocated to thedownstream hub 100.

As shown at block 1439, arbiter 1032 further throttles the transmissionof system-wide broadcast requests by issuing a system-wide broadcastrequest only if the request address does not hash to the same bank 1912of a banked resource 1910 as any of a R−1 prior requests buffered withinprevious request FIFO buffer 911, where 1/R is the fraction of themaximum arrival rate at which the slowest protected snooping device 1900can service requests. Thus, the throttling of system-wide broadcastrequests in the manner shown will limit the number of requests that canarrive at a given snooping device 1900 in a given number of cycles,which can be expressed as:throttled_arr_rate=N requests per R cycleswhere N is the number of processing nodes 202. Snooping devices 1900 arepreferably designed to handle requests arriving at such a throttledarrival rate without retry.

Referring finally to the condition shown at block 1440, arbiter 1032permits a request to be output by local hub request multiplexer 1030only if an entry is available for allocation in LH tag FIFO queue 924 a(block 1440).

If a negative determination is made at any of blocks 1434-1440, therequest is delayed, as indicated at block 1442, until a subsequent cycleduring which all of the determinations illustrated at blocks 1434-1440are positive. If, on the other hand, positive determinations are made atall of blocks 1434-1440, arbiter 1032 signals local hub requestmultiplexer 1030 to output the selected request to an input ofmultiplexer 920, which always gives priority to a request, if any,presented by LH address launch buffer 910. Thus, multiplexer 920 issuesthe request on snoop bus 922. It should be noted that the other ports ofmultiplexer 920 (e.g., RH, RLX, RLY, and RLZ) could present requestsconcurrently with LH address launch buffer 910, meaning that the maximumbandwidth of snoop bus 922 must equal 10/8 (assuming the embodiment ofFIG. 7B) of the bandwidth of the outbound A and B links in order to keepup with maximum arrival rate.

It should also be observed that only requests buffered within local hubaddress launch buffer 910 are transmitted on the outbound A and B linksand are required to be aligned with address tenures within the linkinformation allocation. Because all other requests competing forissuance by multiplexer 920 target only the local snoopers 304 and theirrespective FIFO queues rather than the outbound A and B links, suchrequests may be issued in the remaining cycles of the informationframes. Consequently, regardless of the particular arbitration schemeemployed by multiplexer 920, all requests concurrently presented tomultiplexer 920 are guaranteed to be transmitted within the latency of asingle information frame.

As indicated at block 1444, in response to the issuance of the requeston snoop bus 922, LH tag FIFO queue 924 a records the master tagspecified in the request in the master tag field 1100 of the nextavailable entry. The request is then routed to the outbound A and Blinks, as shown at block 1446. The process then passes through pageconnector 1448 to FIG. 13B, which depicts the processing of the requestat each of the remote hubs during the request phase.

The process depicted in FIG. 13B also proceeds from block 1446 to block1450, which illustrates local hub 100 freeing the local hub tokenallocated to the request in response to the removal of the request fromLH address launch buffer 910. The request is further routed to thesnoopers 304 in the local hub 100, as shown at block 1452. In responseto receipt of the request, snoopers 304 generate a partial response(block 1454), which is recorded within LH partial response FIFO queue930 (block 1456). In particular, at block 1456, an entry 1200 in the LHpartial response FIFO queue 930 is allocated to the request by referenceto allocation pointer 1210, allocation pointer 1210 is incremented, thepartial response of the local hub is placed within the partial responsefield 1202 of the allocated entry, and the local (L) flag is set in theresponse flag field 1204. Thereafter, request phase processing at thelocal hub 100 ends at block 1458.

Referring now to FIG. 13C, there is depicted a high level logicalflowchart of an exemplary method of request processing at a remote hub(or for a node-only broadcast request, a node master) 100 in accordancewith the present invention. As depicted, for a system-wide or supernodebroadcast request, the process begins at page connector 1448 uponreceipt of the request at the remote hub 100 on one of its inbound A andB links. As noted above, after the request is latched into a respectiveone of hold buffers 902 a-902 b as shown at block 1460, the request isevaluated by remote hub multiplexer 903 and request multiplexer 904 fortransmission on request bus 905, as depicted at blocks 1464 and 1465.Specifically, at block 1464, remote hub multiplexer 903 determineswhether to output a system-wide broadcast request in accordance with afair allocation policy that evenly allocates address tenures to requestsreceived on the inbound second tier links. (A supernode request isalways the “winning” request since no competing request will beconcurrently sourced on the other second tier link by the node master100.) In addition, at illustrated at block 1465, request multiplexer904, which is timeslice-aligned with the first tier link informationallocation, outputs a request only if an address tenure is thenavailable. Thus, as shown at block 1466, if a request is not a winningrequest under the fair allocation policy of multiplexer 903, ifapplicable, or if no address tenure is then available, multiplexer 904waits for the next address tenure. It will be appreciated, however, thateven if a request received on an inbound second tier link is delayed,the delay will be no more than one frame of the first tier linkinformation allocation.

If both the conditions depicted at blocks 1464 and 1465 are met,multiplexer 904 launches the request on request bus 905, and the processproceeds from block 1465 to block 1468. As indicated, request phaseprocessing at the node master 100, which continues at block 1423 fromblock 1421 of FIG. 13A, also passes to block 1468. Block 1468illustrates the routing of the request issued on request bus 905 to theoutbound X, Y and Z links, as well as to NM/RH hold buffer 906.Following block 1468, the process bifurcates. A first path passesthrough page connector 1470 to FIG. 13D, which illustrates an exemplarymethod of request processing at the remote (or node) leaves 100. Thesecond path from block 1468 proceeds to block 1474, which illustratesthe snoop multiplexer 920 determining which of the requests presented atits inputs to output on snoop bus 922. As indicated, snoop multiplexer920 prioritizes local hub requests over remote hub requests, which arein turn prioritized over requests buffered in NL/RL hold buffers 914a-914 c. Thus, if a local hub request is presented for selection by LHaddress launch buffer 910, the request buffered within NM/RH hold buffer906 is delayed, as shown at block 1476. If, however, no request ispresented by LH address launch buffer 910, snoop multiplexer 920 issuesthe request from NM/RH hold buffer 906 on snoop bus 922. (In the case ofa supernode request, no competing request is presented by LH addresslaunch buffer 910, and the determination depicted at block 1474 willalways have a negative outcome.)

In response to detecting the request on snoop bus 922, the appropriateone of tag FIFO queues 924 b (i.e., at the node master, NM tag FIFOqueue 924 b 2 or, at the remote hub, the one of RH tag FIFO queues 924 b0 and 924 b 1 associated with the inbound second tier link on which therequest was received) places the master tag specified by the requestinto master tag field 1100 of its next available entry (block 1478). Asnoted above, node-only broadcast requests and system-wide broadcastrequests are differentiated by a scope indicator 730 within the Ttypefield 700 of the request, while the supernode mode is indicated byconfiguration register 123. The request is further routed to thesnoopers 304 in the node master 100 or remote hub 100, as shown at block1480. Thereafter, the process bifurcates and proceeds to each of blocks1482 and 1479.

Referring first to block 1482, snoopers 304 generate a partial responsein response to receipt of the request and record the partial responsewithin NM/RH partial response FIFO queue 940 (block 1484). Inparticular, an entry 1230 in the NM/RH partial response FIFO queue 940is allocated to the request by reference to its allocation pointer 1210,the allocation pointer 1210 is incremented, the partial response of theremote hub is placed within the partial response field 1202, and thenode master/remote flag (NM/R) is set in the response flag field 1234.It should be noted that NM/RH partial response FIFO queue 940 thusbuffers partial responses for operations of differing scope in the samedata structure. In addition, as indicated by blocks 1483 and 1485, ifthe request is a supernode request at the node master 100, the partialresponse of the processor 100 is further shadowed within an entry 1200of LH partial response FIFO queue 930, and the Local flag withinresponse flag array 1204 is set. Following either block 1483 or block1485, request phase processing at the node master 100 or remote hub 100ends at block 1486.

Turning now to block 1479, if configuration register 123 indicates asupernode mode and the processor is the node master 100, the request isfurther routed to a predetermined one of the second tier links (e.g.,link A). The process then passes through block 1477 to block 1448,representing the request phase processing of the request at the remotehub 100. If, on the other hand, a negative determination is made atblock 1479, the process simply terminates at block 1481.

With reference now to FIG. 13D, there is illustrated a high levellogical flowchart of an exemplary method of request processing at aremote leaf (or node leaf) 100 in accordance with the present invention.As shown, the process begins at page connector 1470 upon receipt of therequest at the remote leaf or node leaf 100 on one of its inbound X, Yand Z links. As indicated at block 1490, in response to receipt of therequest, the request is latched into of the particular one of NL/RL holdbuffers 914 a-914 c associated with the first tier link upon which therequest was received. Next, as depicted at block 1491, the request isevaluated by snoop multiplexer 920 together with the other requestspresented to its inputs. As discussed above, snoop multiplexer 920prioritizes local hub requests over remote hub requests, which are inturn prioritized over requests buffered in NL/RL hold buffers 914 a-914c. Thus, if a local hub or remote hub request is presented forselection, the request buffered within the NL/RL hold buffer 914 isdelayed, as shown at block 1492. If, however, no higher priority requestis presented to snoop multiplexer 920, snoop multiplexer 920 issues therequest from the NL/RL hold buffer 914 on snoop bus 922, fairly choosingbetween X, Y and Z requests.

In response to detecting request on snoop bus 922, the particular one oftag FIFO queues 924 c 0-924 c 2, 924 d 0-924 c 2 and 924 e 0-924 e 2associated with the scope of the request and the route by which therequest was received places the master tag specified by the request intothe master tag field 1100 of its next available entry (block 1493). Thatis, the scope indicator 730 within the Ttype field 700 of the request isutilized to determine whether the request is of node-only or system-widescope, while the setting of configuration register 123 is utilized toindicate the supernode mode. For node-only and supernode broadcastrequests, the particular one of NL tag FIFO queues 924 c 2, 924 d 2 and924 e 2 associated with the inbound first tier link upon which therequest was received buffers the master tag. For system-wide andsupernode broadcast requests, the master tag is placed in the particularone of RL tag FIFO queues 924 c 0-924 c 1, 924 d 0-924 d 1 and 924 e0-924 e 1 in the remote node corresponding to the combination of inboundfirst and second tier links upon which the request was received. Therequest is further routed to the snoopers 304 in the remote leaf 100, asshown at block 1494. In response to receipt of the request, the snoopers304 process the request, generate their respective partial responses,and accumulate the partial responses to obtain the partial response ofthat processing unit 100 (block 1495). As indicated by page connector1497, the partial responses of the snoopers 304 of the remote leaf ornode leaf 100 are handled in accordance with FIG. 15A, which isdescribed below.

FIG. 13E is a high level logical flowchart of an exemplary method bywhich snoopers 304 generate partial responses for requests, for example,at blocks 1454, 1482 and 1495 of FIGS. 13B-13D. The process begins atblock 1401 in response to receipt by a snooper 304 (e.g., an IMC snooper126, L2 cache snooper 116 or a snooper within an I/O controller 128) ofa request. In response to receipt of the request, the snooper 304determines by reference to the transaction type specified by the requestwhether or not the request is a write-type request, such as a castoutrequest, write request, or partial write request. In response to thesnooper 304 determining at block 1403 that the request is not awrite-type request (e.g., a read or RWITM request), the process proceedsto block 1405, which illustrates the snooper 304 generating the partialresponse for the request, if required, by conventional processing. If,however, the snooper 304 determines that the request is write-typerequest, the process proceeds to block 1407.

Block 1407 depicts the snooper 304 determining whether or not it is theLPC for the request address specified by the write-type request. Forexample, snooper 304 may make the illustrated determination by referenceto one or more base address registers (BARs) and/or address hashfunctions specifying address range(s) for which the snooper 304 isresponsible (i.e., the LPC). If snooper 304 determines that it is notthe LPC for the request address, the process passes to block 1409. Block1409 illustrates snooper 304 generating a write request partial response720 (FIG. 7C) in which the valid field 722 and the destination tag field724 are formed of all ‘0’s, thereby signifying that the snooper 304 isnot the LPC for the request address. If, however, snooper 304 determinesat block 1407 that it is the LPC for the request address, the processpasses to block 1411, which depicts snooper 304 generating a writerequest partial response 720 in which valid field 722 is set to ‘1’ anddestination tag field 724 specifies a destination tag or route thatuniquely identifies the location of snooper 304 within data processingsystem 200. Following either of blocks 1409 or 1411, the process shownin FIG. 13E ends at block 1413.

VII. Partial Response Phase Structure and Operation

Referring now to FIG. 14, there is depicted a block diagram illustratingan exemplary embodiment of the partial response logic 121 b withininterconnect logic 120 of FIG. 1. As shown, partial response logic 121 bincludes route logic 1500 that routes a remote partial responsegenerated by the snoopers 304 at a remote leaf (or node leaf) 100 backto the remote hub (or node master) 100 from which the request wasreceived via the appropriate one of outbound first tier X, Y and Zlinks. In addition, partial response logic 121 b includes combininglogic 1502 and route logic 1504. Combining logic 1502 accumulatespartial responses received from remote (or node) leaves 100 with otherpartial response(s) for the same request that are buffered within NM/RHpartial response FIFO queue 940. For a node-only broadcast operation,the combining logic 1502 of the node master 100 provides the accumulatedpartial response directly to response logic 122. For a system-wide orsupernode broadcast operation, combining logic 1502 supplies theaccumulated partial response to route logic 1504, which routes theaccumulated partial response to the local hub 100 via one of outbound Aand B links.

Partial response logic 121 b further includes hold buffers 1506 a-1506b, which receive and buffer partial responses from remote hubs 100, amultiplexer 1507, which applies a fair arbitration policy to select fromamong the partial responses buffered within hold buffers 1506 a-1506 b,and broadcast logic 1508, which broadcasts the partial responsesselected by multiplexer 1507 to each other processing unit 100 in itsprocessing node 202. As further indicated by the path coupling theoutput of multiplexer 1507 to programmable delay 1509, multiplexer 1507performs a local broadcast of the partial response that is delayed byprogrammable delay 1509 by approximately one first tier link latency sothat the locally broadcast partial response is received by combininglogic 1510 at approximately the same time as the partial responsesreceived from other processing units 100 on the inbound X, Y and Zlinks. Combining logic 1510 accumulates the partial responses receivedon the inbound X, Y and Z links and the locally broadcast partialresponse received from an inbound second tier link with the locallygenerated partial response (which is buffered within LH partial responseFIFO queue 930) and, when not in supernode mode, passes the accumulatedpartial response to response logic 122 for generation of the combinedresponse for the request.

With reference now to FIGS. 15A-15C, there are illustrated flowchartsrespectively depicting exemplary processing during the partial responsephase of an operation at a remote leaf (and the node leaf), remote hub(and the node master for non-supernode mode operations), and local hub(or the node master for supernode mode operations). In these figures,transmission of partial responses may be subject to various delays thatare not explicitly illustrated. However, because there is no timingconstraint on partial response latency as discussed above, such delays,if present, will not induce errors in operation and are accordingly notdescribed further herein.

Referring now specifically to FIG. 15A, partial response phaseprocessing at the remote leaf (or node leaf) 100 begins at block 1600when the snoopers 304 of the remote leaf (or node leaf) 100 generatepartial responses for the request. As shown at block 1602, route logic1500 then routes, using the remote partial response field 712 of thelink information allocation, the partial response to the remote hub 100for the request via the outbound X, Y or Z link corresponding to theinbound first tier link on which the request was received. As indicatedabove, the inbound first tier link on which the request was received isindicated by which one of tag FIFO queues 924 c 0-924 c 2, 924 d 0-924 d2 and 924 e 0-924 e 2 holds the master tag for the request. Thereafter,partial response processing continues at the remote hub (or node master)100, as indicated by page connector 1604 and as described below withreference to FIG. 15B.

With reference now to FIG. 15B, there is illustrated a high levellogical flowchart of an exemplary embodiment of a method of partialresponse processing at a remote hub (and at the node master fornon-supernode mode operations) in accordance with the present invention.The illustrated process begins at page connector 1604 in response toreceipt of the partial response of one of the remote leaves (or nodeleaves) 100 coupled to the remote hub (or node master) 100 by one of thefirst tier X, Y and Z links. In response to receipt of the partialresponse, combining logic 1502 reads out the entry 1230 within NM/RHpartial response FIFO queue 940 allocated to the operation. The entry isidentified by the FIFO ordering observed within NM/RH partial responseFIFO queue 940, as indicated by the X, Y or Z pointer 1216-1220associated with the link on which the partial response was received.Combining logic 1502 then accumulates the partial response of the remote(or node) leaf 100 with the contents of the partial response field 1202of the entry 1230 that was read. As mentioned above, the accumulationoperation is preferably a non-destructive operation, such as a logicalOR operation. As indicated at blocks 1605 and 1607, for requests at thenode master 100 in the supernode mode, the accumulated partial responseis further shadowed within an entry 1200 of LH partial response FIFOqueue 930, and the appropriate flag within response flag array 1204 isset. Following either block 1605 or block 1607, the process proceeds toblock 1614. At block 1614, combining logic 1502 determines by referenceto the response flag array 1234 of the entry 1230 in NM/RH partialresponse FIFO queue 940 whether, with the partial response received atblock 1604, all of the remote (or node) leaves 100 have reported theirrespective partial responses. If not, the process proceeds to block1616, which illustrates combining logic 1502 updating the partialresponse field 1202 of the entry 1230 allocated to the operation withthe accumulated partial response, setting the appropriate flag inresponse flag array 1234 to indicate which remote (or node) leaf 100provided a partial response, and advancing the associated one ofpointers 1216-1220. Thereafter, the process ends at block 1618.

Referring again to block 1614, in response to a determination bycombining logic 1502 that all remote (or node) leaves 100 have reportedtheir respective partial responses for the operation, combining logic1502 deallocates the entry 1230 for the operation from NM/RH partialresponse FIFO queue 940 by reference to deallocation pointer 1212 (block1620). Next, as depicted at block 1621, combining logic 1502 examinesthe route field 1236 of the deallocated entry to determine the scope ofthe operation. If the route field 1236 of the deallocated entryindicates that the operation being processed at a remote node, combininglogic 1502 routes the accumulated partial response to the particular oneof the outbound A and B links indicated by the contents of route field1236 utilizing the remote partial response field 712 in the linkallocation information, as depicted at block 1622. (Partial responsesfor operations in the supernode mode are preferably transmitted on apredetermined one of the second tier links (e.g., link A).) Thereafter,the process passes through page connector 1624 to FIG. 15C. Referringagain to block 1621, if the route field 1236 of the entry indicates thatthe operation is being processed at the node master 100, combining logic1502 provides the accumulated partial response directly to responselogic 122, if configuration register 123 does not indicate the supernodemode (block 1617). Thereafter, the process passes through page connector1625 to FIG. 17A, which is described below. If, however, combining logic1502 determines at block 1617 that configuration register 123 indicatesthe supernode mode, the process simply ends at block 1619 withoutcombining logic 1502 routing the partial response deallocated from NM/RHpartial response FIFO queue 940 to response logic 122. No such routingis required because the combined response for such operations isgenerated from the shadowed copy maintained by LH partial response FIFOqueue 930, as described below with reference to FIG. 15C.

Referring now to FIG. 15C, there is depicted a high level logicalflowchart of an exemplary method of partial response processing at alocal hub 100 (including the local master 100 or the node master 100 forthe supernode mode) in accordance with an embodiment of the presentinvention. The process begins at block 1624 in response to receipt atthe local hub 100 of a partial response from a remote hub 100 via one ofthe inbound A and B links. Upon receipt, the partial response is placedwithin the hold buffer 1506 a, 1506 b coupled to the inbound second tierlink upon which the partial response was received (block 1626). Asindicated at block 1627, if configuration register 123 does not indicatesupernode mode, multiplexer 1507 applies a fair arbitration policy toselect from among the partial responses buffered within hold buffers1506 a-1506 b. Thus, if the partial response is not selected by the fairarbitration policy, broadcast of the partial response is delayed, asshown at block 1628. Once the partial response is selected, ifnecessary, by a fair arbitration policy, possibly after a delay,multiplexer 1507 outputs the partial response to broadcast logic 1508and programmable delay 1509. The output bus of multiplexer 1507 will notbecome overrun by partial responses because the arrival rate of partialresponses is limited by the rate of request launch. As indicated byblock 1625, the process next proceeds to block 1629, if configurationregister 123 does not indicate the supernode mode and otherwise omitsblock 1629 and proceeds directly to block 1630.

Block 1629 depicts broadcast logic 1508 broadcasting the partialresponses selected by multiplexer 1507 to each other processing unit 100in its processing node 202 via the first tier X, Y and Z links, andmultiplexer 1507 performing a local broadcast of the partial response byoutputting the partial response to programmable delay 1509. Thereafter,the process bifurcates and proceeds to each of block 1631, whichillustrates the continuation of partial response phase processing at theother local hubs 100, and block 1630. As shown at block 1630, ifconfiguration register 123 does not indicate the supernode mode, thepartial response broadcast within the present local hub 100 is delayedby a selectively applied programmable delay 1509 by approximately thetransmission latency of a first tier link so that the locally broadcastpartial response is received by combining logic 1510 at approximatelythe same time as the partial response(s) received from other processingunits 100 on the inbound X, Y and Z links. As illustrated at block 1640,combining logic 1510 accumulates the locally broadcast partial responseof the remote hub 100 with the partial response(s) received from theinbound first tier link(s) and with the locally generated partialresponse, which is/are buffered within LH partial response FIFO queue930.

In order to accumulate the partial responses, combining logic 1510 firstreads out the entry 1200 within LH partial response FIFO queue 930allocated to the operation. The entry is identified by the FIFO orderingobserved within LH partial response FIFO queue 930, as indicated by theparticular one of pointers 1214, 1215 corresponding to the link uponwhich the locally broadcast partial response was received. Combininglogic 1510 then accumulates the locally broadcast partial response ofthe remote hub 100 with the contents of the partial response field 1202of the entry 1200 that was read. Next, as shown at blocks 1642,combining logic 1510 further determines by reference to the responseflag array 1204 of the entry 1200 whether or not, with the currentlyreceived partial response(s), partial responses have been received fromeach processing unit 100 from which a partial response was expected. Ifnot, the process passes to block 1644, which depicts combining logic1510 updating the entry 1200 read from LH partial response FIFO queue930 with the newly accumulated partial response. Thereafter, the processends at block 1646.

Returning to block 1642, if combining logic 1510 determines that allprocessing units 100 from which partial responses are expected havereported their partial responses, the process proceeds to block 1650.Block 1650 depicts combining logic 1510 deallocating the entry 1200allocated to the operation from LH partial response FIFO queue 930 byreference to deallocation pointer 1212. Combining logic 1510 then passesthe accumulated partial response to response logic 122 for generation ofthe combined response, as depicted at block 1652. Thereafter, theprocess passes through page connector 1654 to FIG. 17A, whichillustrates combined response processing at the local hub (or nodemaster) 100.

Referring now to block 1632, processing of partial response(s) receivedby a local hub 100 on one or more first tier links in the non-supernodemode begins when the partial response(s) is/are received by combininglogic 1510. As shown at block 1634, combining logic 1510 may apply smalltuning delays to the partial response(s) received on the inbound firsttier links in order to synchronize processing of the partial response(s)with each other and the locally broadcast partial response. Thereafter,the partial response(s) are processed as depicted at block 1640 andfollowing blocks, which have been described.

VIII. Combined Response Phase Structure and Operation

Referring now to FIG. 16, there is depicted a block diagram of exemplaryembodiment of the combined response logic 121 c within interconnectlogic 120 of FIG. 1 in accordance with the present invention. As shown,combined response logic 121 c includes hold buffers 1702 a-1702 b, whicheach receives and buffers combined responses from a remote hub 100coupled to the local hub 100 by a respective one of inbound A and Blinks. The outputs of hold buffers 1702 a-1702 b form two inputs of afirst multiplexer 1704, which applies a fair arbitration policy toselect from among the combined responses, if any, buffered by holdbuffers 1702 a-1702 b for launch onto first bus 1705 within a combinedresponse field 710 of an information frame.

First multiplexer 1704 has a third input by which combined responses ofnode-only broadcast operations are presented by response logic 122 forselection and launch onto first bus 1705 within a combined responsefield 710 of an information frame in the absence of any combinedresponse in hold buffers 1702 a-1702 b. Because first multiplexer 1704always gives precedence to combined responses for system-wide broadcastoperations received from remote hubs 100 over locally generated combinedresponses for node-only broadcast operations, response logic 122 may,under certain operating conditions, have to wait a significant period inorder for first multiplexer 1704 to select the combined response itpresents. Consequently, in the worst case, response logic 122 must beable to queue a number of combined response and partial response pairsequal to the number of entries in NM tag FIFO queue 924 b 2, whichdetermines the maximum number of node-only broadcast operations that agiven processing unit 100 can have in flight at any one time. Even ifthe combined responses are delayed for a significant period, theobservation of the combined response by masters 300 and snoopers 304will be delayed by the same amount of time. Consequently, delayinglaunch of the combined response does not risk a violation of the timingconstraint set forth above because the time between observation of thecombined response by the winning master 300 and observation of thecombined response by the owning snooper 304 is not thereby decreased.

First bus 1705 is coupled to each of the outbound X, Y and Z links and anode master/remote hub (NM/RH) buffer 1706. For node-only broadcastoperations, NM/RH buffer 1706 buffers a combined response andaccumulated partial response (i.e., destination tag) provided by theresponse logic 122 at this node master 100.

The inbound first tier X, Y and Z links are each coupled to a respectiveone of remote leaf (RL) buffers 1714 a-1714 c. The outputs of NM/RHbuffer 1706 and RL buffers 1714 a-1714 c form 4 inputs of a secondmultiplexer 1720. Second multiplexer 1720 has an additional fifth inputcoupled to the output of a local hub (LH) hold buffer 1710 that, for asystem-wide broadcast operation, buffers a combined response andaccumulated partial response (i.e., destination tag) provided by theresponse logic 122 at this local hub 100. The output of secondmultiplexer 1720 drives combined responses onto a second bus 1722 towhich tag FIFO queues 924 and the outbound second tier links arecoupled. As illustrated, tag FIFO queues 924 are further coupled toreceive, via an additional channel, an accumulated partial response(i.e., destination tag) buffered in LH hold buffer 1710 or NM/RH buffer1706. Masters 300 and snoopers 304 are further coupled to tag FIFOqueues 924. The connections to tag FIFO queues 924 permits snoopers 304to observe the combined response and permits the relevant master 300 toreceive the combined response and destination tag, if any.

Without the window extension 312 b described above, observation of thecombined response by the masters 300 and snoopers 304 at substantiallythe same time could, in some operating scenarios, cause the timingconstraint term regarding the combined response latency from the winningmaster 300 to snooper 304 n (i.e., C_lat(WM_S)) to approach zero,violating the timing constraint. However, because window extension 312 bhas a duration of approximately the first tier link transmissionlatency, the timing constraint set forth above can be satisfied despitethe substantially concurrent observation of the combined response bymasters 300 and snoopers 304.

With reference now to FIGS. 17A-17C, there are depicted high levellogical flowcharts respectively depicting exemplary combined responsephase processing at a local hub (or node master), remote hub (or nodemaster), and remote leaf (or node leaf) in accordance with an exemplaryembodiment of the present invention. Referring now specifically to FIG.17A, combined response phase processing at the local hub (or nodemaster) 100 begins at block 1800 and then proceeds to block 1802, whichdepicts response logic 122 generating the combined response for anoperation based upon the type of request and the accumulated partialresponse. As indicated at blocks 1803-1805, if the scope indicator 730within the combined response 710 indicates that the operation is anode-only broadcast operation or configuration register 123 indicatesthe supernode mode, combined response phase processing at the nodemaster 100 continues at block 1863 of FIG. 17B. However, if the scopeindicator 730 indicates that the operation is a system-wide broadcastoperation, response logic 122 of the remote hub 100 places the combinedresponse and the accumulated partial response into LH hold buffer 1710,as shown at block 1804. By virtue of the accumulation of partialresponses utilizing an OR operation, for write-type requests, theaccumulated partial response will contain a valid field 722 set to ‘1’to signify the presence of a valid destination tag within theaccompanying destination tag field 724. For other types of requests, bit0 of the accumulated partial response will be set to ‘0’ to indicatethat no such destination tag is present.

As depicted at block 1844, second multiplexer 1720 is time-slice alignedwith the selected second tier link information allocation and selects acombined response and accumulated partial response from LH hold buffer1710 for launch only if an address tenure is then available for thecombined response in the outbound second tier link informationallocation. Thus, for example, second multiplexer 1720 outputs acombined response and accumulated partial response from LH hold buffer1710 only during cycle 1 or 3 of the embodiment of FIG. 7B. If anegative determination is made at block 1844, the launch of the combinedresponse within LH hold buffer 1710 is delayed, as indicated at block1846, until a subsequent cycle during which an address tenure isavailable. If, on the other hand, a positive determination is made atblock 1844, second multiplexer 1720 preferentially selects the combinedresponse. within LH hold buffer 1710 over its other inputs for launchonto second bus 1722 and subsequent transmission on the outbound secondtier links.

It should also be noted that the other ports of second multiplexer 1720(e.g., RH, RLX, RLY, and RLZ) could also present requests concurrentlywith LH hold buffer 1710, meaning that the maximum bandwidth of secondbus 1722 must equal 10/8 (assuming the embodiment of FIG. 7B) of thebandwidth of the outbound second tier links in order to keep up withmaximum arrival rate. It should further be observed that only combinedresponses buffered within LH hold buffer 1710 are transmitted on theoutbound second tier links and are required to be aligned with addresstenures within the link information allocation. Because all othercombined responses competing for issuance by second multiplexer 1720target only the local masters 300, snoopers 304 and their respectiveFIFO queues rather than the outbound second tier links, such combinedresponses may be issued in the remaining cycles of the informationframes. Consequently, regardless of the particular arbitration schemeemployed by second multiplexer 1720, all combined responses concurrentlypresented to second multiplexer 1720 are guaranteed to be transmittedwithin the latency of a single information frame.

Following the issuance of the combined response on second bus 1722, theprocess bifurcates and proceeds to each of blocks 1848 and 1852. Block1848 depicts routing the combined response launched onto second bus 1722to the outbound second tier links for transmission to the remote hubs100. Thereafter, the process proceeds through page connector 1850 toFIG. 17C, which depicts an exemplary method of combined responseprocessing at the remote hubs 100.

Referring now to block 1852, the combined response issued on second bus1722 is also utilized to query LH tag FIFO queue 924 a to obtain themaster tag from the oldest entry therein. Thereafter, LH tag FIFO queue924 a deallocates the entry allocated to the operation (block 1854).Following block 1854, the process bifurcates and proceeds to each ofblocks 1810 and 1856. At block 1810, LH tag FIFO queue 924 a determineswhether the master tag indicates that the master 300 that originated therequest associated with the combined response resides in this local hub100. If not, processing in this path ends at block 1816. If, however,the master tag indicates that the originating master 300 resides in thepresent local hub 100, LH tag FIFO queue 924 a routes the master tag,the combined response and the accumulated partial response to theoriginating master 300 identified by the master tag (block 1812). Inresponse to receipt of the combined response and master tag, theoriginating master 300 processes the combined response, and if thecorresponding request was a write-type request, the accumulated partialresponse (block 1814).

For example, if the combined response indicates “success” and thecorresponding request was a read-type request (e.g., a read, DClaim orRWITM request), the originating master 300 may update or prepare toreceive a requested memory block. In this case, the accumulated partialresponse is discarded. If the combined response indicates “success” andthe corresponding request was a write-type request (e.g., a castout,write or partial write request), the originating master 300 extracts thedestination tag field 724 from the accumulated partial response andutilizes the contents thereof as the data tag 714 used to route thesubsequent data phase of the operation to its destination. If a“success” combined response indicates or implies a grant of HPC statusfor the originating master 300, then the originating master 300 willadditionally begin to protect its ownership of the memory block, asdepicted at reference numerals 313. If, however, the combined responsereceived at block 1814 indicates another outcome, such as “retry”, theoriginating master 300 may be required to reissue the request, perhapswith a different scope (e.g., global rather than local). Thereafter, theprocess ends at block 1816.

Referring now to block 1856, LH tag FIFO queue 924 a also routes thecombined response and the associated master tag to the snoopers 304within the local hub 100. In response to receipt of the combinedresponse, snoopers 304 process the combined response and perform anyoperation required in response thereto (block 1857). For example, asnooper 304 may source a requested memory block to the originatingmaster 300 of the request, invalidate a cached copy of the requestedmemory block, etc. If the combined response includes an indication thatthe snooper 304 is to transfer ownership of the memory block to therequesting master 300, snooper 304 appends to the end of its protectionwindow 312 a a programmable-length window extension 312 b, which, forthe illustrated topology, preferably has a duration of approximately thelatency of one chip hop over a first tier link (block 1858). Of course,for other data processing system topologies and differentimplementations of interconnect logic 120, programmable window extension312 b may be advantageously set to other lengths to compensate fordifferences in link latencies (e.g., different length cables couplingdifferent processing nodes 202), topological or physical constraints,circuit design constraints, or large variability in the boundedlatencies of the various operation phases. Thereafter, combined responsephase processing at the local hub 100 ends at block 1859.

Referring now to FIG. 17B, there is depicted a high level logicalflowchart of an exemplary method of combined response phase processingat a remote hub (or node master) 100 in accordance with the presentinvention. As depicted, for combined response phase processing at aremote hub 100, the process begins at page connector 1860 upon receiptof a combined response at a remote hub 100 on one of its inbound A or Blinks. The combined response is then buffered within the associated oneof hold buffers 1702 a-1702 b, as shown at block 1862. The bufferedcombined response is then transmitted by first multiplexer 1704 on firstbus 1705 as soon as the conditions depicted at blocks 1864 and 1865 areboth met. In particular, an address tenure must be available in thefirst tier link information allocation (block 1864) and the fairallocation policy implemented by first multiplexer 1704 must select thehold buffer 1702 a, 1702 b in which the combined response is buffered(block 1865). As described previously, in the supernode mode, the holdbuffer 1702 a buffering the combined response is always the winner ofthe fair allocation policy of first multiplexer 1704 because there areno operations competing for access to first bus 1705 on the other secondtier link(s).

As shown at block 1864, if either of these conditions is not met, launchof the combined response by first multiplexer 1704 onto first bus 1705is delayed at block 1866 until the next address tenure. If, however,both conditions illustrated at blocks 1864 and 1865 are met, the processproceeds from block 1865 to block 1868, which illustrates firstmultiplexer 1704 broadcasting the combined response on first bus 1705 tothe outbound X, Y and Z links and NM/RH hold buffer 1706 within acombined response field 710. As indicated by the connection of the pathcontaining blocks 1863 and 1867 to block 1868, for node-only andsupernode broadcast operations, first multiplexer 1704 issues thecombined response presented by response logic 122 onto first bus 1705for routing to the outbound X, Y and Z links and NM/RH hold buffer 1706only if no competing combined responses are presented by hold buffers1702 a-1702 b. If any competing combined response is received for asystem-wide broadcast operation from a remote hub 100 via one of theinbound second tier links, the locally generated combined response forthe node-only broadcast operation is delayed, as shown at block 1867.When first multiplexer 1704 finally selects the locally generatedcombined response for the node-only broadcast operation, response logic122 places the associated accumulated partial response directly intoNM/RH hold buffer 1706.

Following block 1868, the process bifurcates. A first path passesthrough page connector 1870 to FIG. 17C, which illustrates an exemplarymethod of combined response phase processing at the remote leaves (ornode leaves) 100. The second path from block 1868 proceeds to block1874, which illustrates the second multiplexer 1720 determining which ofthe combined responses presented at its inputs to output onto second bus1722. As indicated, second multiplexer 1720 prioritizes local hubcombined responses over remote hub combined responses, which are in turnprioritized over combined responses buffered in remote leaf buffers 1714a-1714 c. Thus, if a local hub combined response is presented forselection by LH hold buffer 1710, the combined response buffered withinremote hub buffer 1706 is delayed, as shown at block 1876. If, however,no combined response is presented by LH hold buffer 1710 (which isalways the case in supernode mode), second multiplexer 1720 issues thecombined response from NM/RH buffer 1706 onto second bus 1722.

In response to detecting the combined response on second bus 1722, theparticular one of tag FIFO queues 924 b 0 and 924 b 1 associated withthe second tier link upon which the combined response was received (orfor node-only or supernode broadcast operations, NM tag FIFO queue 924 b2) reads out the master tag specified by the relevant request from themaster tag field 1100 of its oldest entry, as depicted at block 1878,and then deallocates the entry (block 1880). The process thentrifurcates and proceeds to each of blocks 1882, 1881, and 1861. Block1882 depicts the relevant one of tag FIFO queues 924 b routing thecombined response and the master tag to the snoopers 304 in the remotehub (or node master) 100. In response to receipt of the combinedresponse, the snoopers 304 process the combined response (block 1884)and perform any required operations, as discussed above. If theoperation is a system-wide or supernode broadcast operation and if thecombined response includes an indication that the snooper 304 is totransfer coherency ownership of the memory block to the requestingmaster 300, the snooper 304 appends a window extension 312 b to itsprotection window 312 a, as shown at block 1885. Thereafter, combinedresponse phase processing at the remote hub 100 ends at block 1886.

Referring now to block 1881, if the scope indicator 730 within thecombined response field 710 and the setting of configuration register123 indicate that the operation is not a node-only or supernodebroadcast operation but is instead a system-wide broadcast operation, nofurther processing is performed at the remote hub 100, and the processends at blocks 1886. If, however, the scope indicator 730 indicates thatthe operation is a node-only broadcast operation or configurationregister 123 indicates the supernode mode and the current processor 100is the node master 100, the process passes to block 1883, whichillustrates NM tag FIFO queue 924 b 2 routing the master tag, thecombined response and the accumulated partial response to theoriginating master 300 identified by the master tag. In response toreceipt of the combined response and master tag, the originating master300 processes the combined response, and if the corresponding requestwas a write-type request, the accumulated partial response (block 1887).

For example, if the combined response indicates “success” and thecorresponding request was a read-type request (e.g., a read, DClaim orRWITM request), the originating master 300 may update or prepare toreceive a requested memory block. In this case, the accumulated partialresponse is discarded. If the combined response indicates “success” andthe corresponding request was a write-type request (e.g., a castout,write or partial write request), the originating master 300 extracts thedestination tag field 724 from the accumulated partial response andutilizes the contents thereof as the data tag 714 used to route thesubsequent data phase of the operation to its destination. If a“success” combined response indicates or implies a grant of HPC statusfor the originating master 300, then the originating master 300 willadditionally begin to protect its ownership of the memory block, asdepicted at reference numerals 313. If, however, the combined responsereceived at block 1814 indicates another outcome, such as “retry”, theoriginating master 300 may be required to reissue the request.Thereafter, the process ends at block 1886.

Turning now to block 1861, if the processing unit 100 processing thecombined response is the node master 100 and configuration register 123indicates the supernode mode, second multiplexer 1720 additionallyroutes the combined response to a selected one of second tier links(e.g., link A), as shown at block 1874. Thereafter, the process passesthrough page connector 1860 and processing of the combined responsecontinues at the remote hub 100.

With reference now to FIG. 17C, there is illustrated a high levellogical flowchart of an exemplary method of combined response phaseprocessing at a remote (or node) leaf 100 in accordance with the presentinvention. As shown, the process begins at page connector 1888 uponreceipt of a combined response at the remote (or node) leaf 100 on oneof its inbound X, Y and Z links. As indicated at block 1890, thecombined response is latched into one of NL/RL hold buffers 1714 a-1714c. Next, as depicted at block 1891, the combined response is evaluatedby second multiplexer 1720 together with the other combined responsespresented to its inputs. As discussed above, second multiplexer 1720prioritizes local hub combined responses over remote hub combinedresponses, which are in turn prioritized over combined responsesbuffered in NL/RL hold buffers 1714 a-1714 c. Thus, if a local hub orremote hub combined response is presented for selection, the combinedresponse buffered within the NL/RL hold buffer 1714 is delayed, as shownat block 1892. If, however, no higher priority combined response ispresented to second multiplexer 1720, second multiplexer 920 issues thecombined response from the NL/RL hold buffer 1714 onto second bus 1722.

In response to detecting the combined response on second bus 1722, theparticular one of tag FIFO queues 924 c 0-924 c 2, 924 d 0-924 d 2, and924 e 0-924 e 2 associated with the scope of the operation and the routeby which the combined response was received reads out from the mastertag field 1100 of its oldest entry the master tag specified by theassociated request, as depicted at block 1893. That is, the setting ofconfiguration register 123 or the scope indicator 730 within thecombined response field 710 is utilized to determine whether the requestis made in the supernode mode, or if not, is of node-only or system-widescope. For node-only and supernode broadcast requests, the particularone of NL tag FIFO queues 924 c 2, 924 d 2 and 924 e 2 associated withthe inbound first tier link upon which the combined response wasreceived buffers the master tag. For system-wide broadcast requests, themaster tag is retrieved from the particular one of RL tag FIFO queues924 c 0-924 c 1, 924 d 0-924 d 1 and 924 e 0-924 e 1 corresponding tothe combination of inbound first and second tier links upon which thecombined response was received.

Once the relevant tag FIFO queue 924 identifies the appropriate entryfor the operation, the tag FIFO queue 924 deallocates the entry (block1894). The combined response and the master tag are further routed tothe snoopers 304 in the remote (or node) leaf 100, as shown at block1895. In response to receipt of the combined response, the snoopers 304process the combined response (block 1896) and perform any requiredoperations, as discussed above. If the operation is not a node-onlyoperation and if the combined response includes an indication that thesnooper 304 is to transfer coherency ownership of the memory block tothe requesting master 300, snooper 304 appends to the end of itsprotection window 312 a, a window extension 312 b, as described aboveand as shown at block 1897. Thereafter, combined response phaseprocessing at the remote leaf 100 ends at block 1898.

IX. Data Phase Structure and Operation

Data logic 121 d and its handling of data delivery can be implemented ina variety of ways. In one preferred embodiment, data logic 121 d and itsoperation are implemented as described in detail in co-pending U.S.patent application incorporated by reference above. Of course, theadditional second tier link(s) unused by request and response flow(e.g., the B links) can be employed for data delivery to enhance databandwidth.

X. Conclusion

As has been described, the present invention provides an improvedprocessing unit, data processing system and interconnect fabric for adata processing system. The inventive data processing system topologydisclosed herein provides high bandwidth communication betweenprocessing units in different processing nodes through theimplementation of point-to-point inter-node links between multipleprocessing units of the processing nodes. In addition, the processingunits and processing nodes disclosed herein exhibit great flexibility inthat the same interconnect logic can support diverse interconnect fabrictopologies as shown, for example, in FIGS. 2A-2B, and thus permit theprocessing nodes of a data processing system to be interconnected in themanner most suitable for anticipated workloads.

While the invention has been particularly shown as described withreference to a preferred embodiment, it will be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.For example, although the present invention discloses preferredembodiments in which FIFO queues are utilized to order operation-relatedtags and partial responses, those skilled in the art will appreciatedthat other ordered data structures may be employed to maintain an orderbetween the various tags and partial responses of operations in themanner described. In addition, although preferred embodiments of thepresent invention employ uni-directional communication links, thoseskilled in the art will understand by reference to the foregoing thatbi-directional communication links could alternatively be employed.Moreover, although the present invention has been described withreference to specific exemplary interconnect fabric topologies, thepresent invention is not limited to those specifically described hereinand is instead broadly applicable to a number of different interconnectfabric topologies.

1. A data processing system, comprising: a first processing node and asecond processing node, wherein: said first processing node includes aplurality of first processing units coupled to each other forcommunication and said second processing node includes a plurality ofsecond processing units coupled to each other for communication; saidplurality of first processing units includes at least first, second andthird processing units and said plurality of second processing unitsincludes at least fourth, fifth and sixth processing units; said firstand fourth processing units are connected by a first point-to-pointlink; said second and fifth processing units are connected by a secondpoint-to-point link; said third and sixth processing units are connectedby a third point-to-point link; said plurality of first processing unitsincludes a node master processing unit and at least one node leafprocessing unit; said plurality of second processing units includes aremote hub processing unit and at least one remote leaf processing unit;said node master processing unit broadcasts a request to each node leafprocessing unit and to said remote hub processing unit; said remote hubprocessing unit broadcasts said request to each remote leaf processingunit; and said node master processing unit broadcasts a combinedresponse for said request to each node leaf processing unit, remote hubprocessing unit and remote leaf processing unit based upon partialresponses for said request received by said node master processing unit.2. The data processing system of claim 1, wherein: said first, secondand third point-to-point links comprise a plurality of point-to-pointsecond tier links; and each of said plurality of first processing unitsis coupled to each other of said plurality of first processing units bya respective one of a plurality of point-to point first tier links. 3.The data processing system of claim 2, wherein each of said plurality offirst processing units includes interconnect logic that broadcastsoperations to all of said plurality of first processing units and all ofsaid plurality of second processing units via all of said plurality offirst tier links and one of said plurality of second tier links.
 4. Adata processing system, comprising: a first processing node and a secondprocessing node, wherein: said first processing node includes aplurality of first processing units coupled to each other forcommunication and said second processing node includes a plurality ofsecond processing units coupled to each other for communication; saidplurality of first processing units includes at least first, second andthird processing units and said plurality of second processing unitsincludes at least fourth, fifth and sixth processing units; said firstand fourth processing units are connected by a first point-to-pointlink; said second and fifth processing units are connected by a secondpoint-to-point link; said third and sixth processing units are connectedby a third point-to-point link; wherein: operations of said plurality offirst and second processing units include, in order, at least a requestphase in which a request is broadcast, a partial response phase in whichindividual processing units determine their respective responses to saidrequest, and a combined response phase in which a system-wide combinedresponse to said request is distributed; and said plurality of first andsecond processing units route said combined response via each linktraversed by said request in a same direction as said request and routeat least one partial response via each link traversed by said request inan opposite direction to said request.
 5. A first processing node for adata processing system including at least said first processing node anda second processing node, said first processing node comprising: aplurality of first processing units coupled to each other forcommunication, wherein each of said plurality of first processing unitsincludes interconnect logic by which each said first processing unit canbe coupled to a respective one of a plurality of second processing unitsin said second processing node by a respective one of a plurality ofpoint-to-point links, such that: a first processing unit in said firstprocessing node is coupled to a fourth processing unit in the secondprocessing node by a first point-to-point link; a second processing unitin said first processing node is coupled to a fifth processing unit inthe second processing node by a second point-to-point link; and a thirdprocessing unit in said first processing node is coupled to a sixthprocessing unit in the second processing node by a third point-to-pointlink; wherein: said plurality of first processing units includes a nodemaster processing unit and at least one node leaf processing unit; saidplurality of second processing units includes a remote hub processingunit and at least one remote leaf processing unit; said node masterprocessing unit broadcasts a request to each node leaf processing unitand to said remote hub processing unit; said node master processing unitbroadcasts a combined response for said request to each node leafprocessing unit, remote hub processing unit and remote leaf processingunit based upon partial responses for said request received by said nodemaster processing unit.
 6. The first processing node of claim 5,wherein: said plurality of point-to-point links comprises a plurality ofpoint-to-point second tier links; and each of said plurality of firstprocessing units is coupled to each other of said plurality of firstprocessing units by a respective one of a plurality of point-to pointfirst tier links.
 7. The first processing node of claim 6, wherein eachof said plurality of first processing units includes interconnect logicthat broadcasts operations to all of said plurality of first processingunits and all of said plurality of second processing units via all ofsaid plurality of first tier links and one of said plurality of secondtier links.
 8. A first processing node for a data processing systemincluding at least said first processing node and a second processingnode, said first processing node comprising: a plurality of firstprocessing units coupled to each other for communication, wherein eachof said plurality of first processing units includes interconnect logicby which each said first processing unit can be coupled to a respectiveone of a plurality of second processing units in said second processingnode by a respective one of a plurality of point-to-point links, suchthat: a first processing unit in said first processing node is coupledto a fourth processing unit in the second processing node by a firstpoint-to-point link; a second processing unit in said first processingnode is coupled to a fifth processing unit in the second processing nodeby a second point-to-point link; and a third processing unit in saidfirst processing node is coupled to a sixth processing unit in thesecond processing node by a third point-to-point link; wherein:operations of said plurality of first processing units include, inorder, at least a request phase in which a request is broadcast, apartial response phase in which individual processing units determinetheir respective responses to said request, and a combined responsephase in which a system-wide combined response to said request isdistributed; and a node master processing unit among said plurality offirst processing units routes said combined response via each linktraversed by said request in a same direction as said request and eachnode leaf processing unit among said plurality of first processing unitsroutes at least one partial response via a link traversed by saidrequest in an opposite direction to said request.